DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Claims 1-20 have been examined in this application. This communication is the first action on the merits.
Priority
Application 19/263,338 filed on 07/08/2025 is a CON of 16/529,086 08/01/2019 ABN.
Examiner Request
The Applicant is requested to indicate where in the specification there is support for amendments to claims should Applicant amend. The purpose of this is to reduce potential 35 U.S.C. § 112(a) or § 112 1st paragraph issues that can arise when claims are amended without support in the specification. The Examiner thanks the Applicant in advance.
Claim Rejections - 35 USC § 112(a)
Claims 1-20 are rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the written description requirement. The claim(s) contain subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for applications subject to pre-AIA 35 U.S.C. 112, the inventor(s), at the time the application was filed, had possession of the claimed invention.
Claims 1, 11, and 18 recite an “incident report”, whereas the originally filed specification describes systems and methods directed to generating insurance claims, processing insurance claims, analyzing insurance claims, issuing insurance claims, assessing insurance claim documents for fraud, and managing insurance claim lifecycles. The specification does not describe or otherwise reasonably convey possession of the broader genus of “incident reports” recited in the claims.
As such, the introduction of this claimed subject matter constitutes new matter not supported by the original disclosure.
Claims 2-10, 12-17, and 19-20 are rejected under 35 U.S.C. 112(a) failing to comply with the written description requirement for the same reasons, because they depend from independent claims 1, 11, and 18. Appropriate correction is required.
Claim Rejections - 35 USC § 101
35 U.S.C. § 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1-20 are rejected under 35 U.S.C. § 101 because the claimed invention is directed to a judicial exception (i.e., a law of nature, a natural phenomenon, or an abstract idea) without significantly more. (MPEP 2106). The claims are directed to a method, system, and apparatus which is one of the statutory categories of invention (Step 1: YES). The recitation of the claimed invention is analyzed as follows, in which the abstract elements are boldfaced.
Claim 1 recites the limitations of:
An image analysis (IA) computer system for classifying and analyzing received documents using artificial intelligence, the IA computer system including at least one processor in communication with at least one memory device, the at least one processor programmed to:
receive, from a user computing device, a processing request including (i) image data representing a document associated with an incident report, and (ii) an identifier of the incident report, the incident report being stored within a database;
execute an extraction module to electronically extract content of the document from the image data;
execute a classification module to classify the document as one document type of a plurality of document types, wherein the classification module applies a document classification model to the extracted content;
execute a content verification module to verify the extracted content based upon the document type of the document;
in response to the extracted content being verified by the content verification module:
update the incident report by storing the extracted content within the database linked to the incident report and the received identifier;
transmit a response to the user computing device indicating the extracted content was verified and applied to the identified incident report; and
further process the incident report; and
in response to the extracted content not being verified by the content verification module:
generate a denial indicator and update the incident report by storing the denial indicator within the database linked to the incident report and the received identifier; and
transmit a response to the user computing device indicating the incident report is denied based upon the extracted content not being verified.
The claim as a whole recites a method that, under its broadest reasonable interpretation, covers the concept of extracting and comparing information on an insurance claim to verify the claim. This is a fundamental economic practice of a financial transaction; a commercial interaction, such as for business relations; and managing personal behavior or relationships or interactions between people, which are certain methods of organizing human activity.
Furthermore, the claims cover the use of a computer system to provide for extracting and comparing information on an insurance claim to verify the claim. As the steps could be performed by a human without a computer, the claim limitations fall within the mental processes grouping, and the claim recites an abstract idea.
Finally, the claims also recite the use of artificial intelligence for identifying content within received images and classifying the content for further analysis and extracting and comparing information on an insurance claim to verify the claim. For example, the specification discloses “[0089] The document classification model may utilize one or more artificial intelligence algorithms, including machine learning techniques for analyzing document content to classify documents.” “[0090] The content verification module may employ one or more artificial intelligence algorithms, including machine learning techniques for comparing, validating, verifying, and/or authenticating document content (e.g., based on historical document content).” This is a mathematical concept or calculation.
In the alternative, the artificial intelligence models are considered a technology that is recited at a high level of generality and merely applied as a tool to implement the abstract idea.
Thus, the claims recite an abstract idea. (Step 2A, prong 1: YES).
Moreover, the judicial exception is not integrated into a practical application. Other than reciting a “An image analysis (IA) computer system for classifying and analyzing received documents using artificial intelligence, the IA computer system including at least one processor in communication with at least one memory device, the at least one processor programmed to:”, “user computing device”, “database”, “extraction module”, “classification module”, “content verification module”, to perform the steps of “extracting”, “classifying”, “verifying”, “updating”, and “generating”, nothing in the claim elements preclude the steps from practically being a certain method of organizing human activity or mental process or mathematical concept or calculation. The claim as a whole does not integrate the judicial exception into a practical application. The claim merely describes how to generally “apply” the concept of extracting and comparing information on an insurance claim to verify the claim in a computer environment. The additional computer elements recited in the claim limitations are recited at a high-level of generality such that it amounts to no more than mere instructions to apply the exception utilizing generic computer components.
For example, the specification at discloses “[0056] User computing devices 110 may be any device capable of accessing the Internet including, but not limited to, a desktop computer, a laptop computer, a personal digital assistant (PDA), a cellular phone, a smartphone, a tablet, a phablet, wearable electronics, smart watch, or other web-based connectable equipment or mobile devices. User computing devices 110 may be any personal computing device and/or any mobile communications device of a user, such as a personal computer, a tablet computer, a smartphone, and the like. User computing devices 110 may be configured to present an application (e.g., a smartphone "app") or a webpage, such as a webpage or an app for submitting documents associated with an insurance claim, viewing progress of the insurance claim, and the like. To this end, user computing devices 110 may include or execute software, such as a web browser, for viewing and interacting with a webpage and/or an app. Although two user computing devices 110 are shown in Figure 1 for clarity, it should be understood that IA computer system 100 may include any number of user computing devices 110.” “[0058] Insurance network 115 computing devices may be any device capable of accessing the Internet including, but not limited to, a desktop computer, a laptop computer, a personal digital assistant (PDA), a cellular phone, a smartphone, a tablet, a phablet, wearable electronics, smart watch, or other web-based connectable equipment or mobile devices. In some embodiments, insurance network 115 computing devices may access database 130 to review submitted documents associated with an insurance claim, review analytics associated with the submitted documents, review trend analyses, update analysis models, determine the status of an in-progress insurance claim, review reimbursement information, and the like.”
Furthermore, the specification discloses “[0089] The document classification model may utilize one or more artificial intelligence algorithms, including machine learning techniques for analyzing document content to classify documents.” “[0090] The content verification module may employ one or more artificial intelligence algorithms, including machine learning techniques for comparing, validating, verifying, and/or authenticating document content (e.g., based on historical document content).” “[0094] Upon upload by the policyholder, IA server 105 receives image data 502. As described herein, IA server 105 is configured to process image data 502 to classify the represented document as one of a plurality of document types and to verify the content of the represented document. To implement these processes, IA server 105 executes one or more modules using a processing component (e.g., a processor 310). The one or modules may include specialized instruction sets or kernel extensions that, upon execution by the processor, cause the processor to perform the functions described herein. The modules may additionally or alternatively include co-processors specifically programmed to perform the described functions.”
Thus, the specification supports that general purpose computers or computer components are utilized to implement the steps of the abstract idea.
Merely implementing the abstract idea on a generic computer is not a practical application of the abstract idea. The claim as a whole, in viewing the additional elements both individually and in combination, does not integrate the judicial exception into a practical application. Accordingly, these additional elements do not integrate the abstract idea into a practical application because it does not impose any meaningful limits on practicing the abstract idea. The claim is directed to an abstract idea. (Step 2A prong two: No)
The claim does not include additional elements, when considered both individually and as an ordered combination, that are sufficient to amount to significantly more than the judicial exception. As discussed above with respect to integration of the abstract idea into a practical application, the additional elements of using “An image analysis (IA) computer system for classifying and analyzing received documents using artificial intelligence, the IA computer system including at least one processor in communication with at least one memory device, the at least one processor programmed to:”, “user computing device”, “database”, “extraction module”, “classification module”, “content verification module”, to perform the steps of “extracting”, “classifying”, “verifying”, “updating”, and “generating”, amounts to no more than mere instructions to apply the exception using generic computer component. The claim merely describes how to generally “apply” the concept of extracting and comparing information on an insurance claim to verify the claim in a computer environment. Thus, even when viewed as a whole, nothing in the claim adds significantly more (i.e. an inventive concept) to the abstract idea. Such additional elements are determined to not contain an inventive concept according to MPEP 2106.05(f). It should be noted that (1) the “recitation of claim limitations that attempt to cover any solution to an identified problem with no restriction on how the result is accomplished and no description of the mechanism for accomplishing the result, does not provide significantly more because this type of recitation is equivalent to the words “apply it”, and (2) “Use of a computer or other machinery in its ordinary capacity for economic or other tasks (e.g., to receive, store, or transmit data) or simply adding a general purpose computer or computer components after the fact to an abstract idea (e.g., a fundamental economic practice, commercial interaction, or managing personal behavior or relationships or interactions between people, mental process, or mathematical calculation) does not integrate a judicial exception into a practical application or provide significantly more”.
Claims 11 and 18 are substantially similar to claim 1, thus, they are rejected on similar grounds.
Claim 11 recites the additional elements of “A computer-implemented method for classifying and analyzing received claim documents using artificial intelligence, the method implemented using an IA computer system including at least one processor in communication with at least one memory device, the method comprising:”.
Claim 18 recites the additional elements of “At least one non-transitory computer-readable storage medium having computer-executable instructions embodied thereon, wherein, when executed by at least one processor of an image analysis (IA) computer system, the computer-executable instructions cause the at least one processor to:”.
Claims 3, 4, 5, 12, 13, and 14 recite the additional elements of “a training module”
Claims 6 and 19 recite the additional elements of “the document classification model is an artificial intelligence-based model that includes at least one of a conditional neural network optical character recognition (OCR) model, a long short term memory OCR model, and a template matching model.”
Claims 8 and 9 recite the additional elements of “causing a graphical user interface to be displayed on an administrator computing device”
For similar reasons as explained above with regard to claim 1, under Step 2A, prong two, these additional elements are merely applying generic computer components to implement the abstract idea. Under Step 2B, when viewing the additional elements individually and in combination, the additional elements do not amount to an inventive concept amounting to significantly more than the judicial exception itself as the claimed computer-related technologies are mere tools for implementing the abstract idea as explained with regard to claim 1.
Dependent claims 2-10, 12-17, and 19-20 merely limit the abstract idea and do not recite any further additional elements beyond the cited abstract idea and the elements addressed above, thus, they do not amount to significantly more. The dependent claims are abstract for the reasons presented above because there are no additional elements that integrate the abstract idea into a practical application or are sufficient to amount to significantly more than the judicial exception when considered both individually and as an ordered combination. Thus, the dependent claims are directed to an abstract idea. (Step 2B: No)
Therefore, claims 1-20 are not patent-eligible.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. §§ 102 and 103 (or as subject to pre-AIA 35 U.S.C. §§ 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. § 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1-2, 6, 11, and 18-19 are rejected under 35 U.S.C. 103 as being unpatentable over Hutchins, U.S. Patent Application Publication Number 2020/0210490; in view of Guo, U.S. Patent Application Publication Number 2020/0211121; in view of Farmer, U.S. Patent Application Publication Number 2021/0004909; in view of Tsai, U.S. Patent Application Publication Number 2020/0192862.
As per claim 1,
Hutchins explicitly teaches:
An image analysis (IA) computer system for classifying and analyzing received documents using artificial intelligence, the IA computer system including at least one processor in communication with at least one memory device, the at least one processor programmed to: receive, from a user computing device, a processing request including (i) image data representing a document associated with an incident report, and
(Hutchins US20200210490 at paras. 30, 70) ("[0030] As an example, on the client side, a user may start a document capture module, service, or application (e.g., document capture module 210) on the user's device (e.g., client device 201) and scan or take a picture of the paper document (e.g., through user interface 212). The document capture module can then send the picture or image of the paper document to a document capture server computer. As discussed below, the document capture module can include an image enhancement function." "[0070] This master document capture workflow or process flow can be defined by a user of the document capture server (e.g., through a workflow facility or user interface with a workflow function). Throughout the master document capture workflow or process flow, the document can be identified via a globally unique identifier assigned by the document capture server computer (e.g., upon capture of the document).")
execute an extraction module to electronically extract content of the document from the image data;
(Hutchins US20200210490 at paras. 3-10, 33-45) ("[0003] An object of the invention is to change the division of labor in processing captured documents by leveraging artificial intelligence (AI) to enhance document capture and to provide insight on unstructured data before providing the captured documents to a downstream computing facility such as a content management system operating in an enterprise computing environment. [0004] Generally, this object can be achieved in a document capture server computer that can import/capture/ingest documents, convert them to appropriate format(s), enhance the documents, and apply optical character recognition (OCR) to the documents. Additionally, the document capture server computer can determine their graphical layouts respectively, extract keywords contained in the documents, and classify the documents based on their respective graphical layouts and/or extracted keywords." "[0033] Likewise, the document capture server computer can analyze a document, identify keywords in the document, extract those keywords from the document, and determine a class for the document based on the keywords extracted from the document. At this processing stage (e.g., document classification and extraction stage 224), the document capture server computer can perform other document analyses such as zonal extraction and freeform extraction for certain types of documents (e.g., documents with forms, documents with regular expressions), etc. Zonal extraction, also referred to as template OCR, can extract text located at a specific location or zone within a document.")
execute a classification module to classify the document as one document type of a plurality of document types, wherein the classification module applies a document classification model to the extracted content;
(Hutchins US20200210490 at paras. 65, 70-71) ("[0065] The prepared document and the textual information can undergo a classification process (which can also be done in a pipeline that includes graphical classification, keyword classification, zonal extraction, and freeform extraction), to determine the type of the document (e.g., a contract, a complaint, a correspondence, a purchase order, a credit card application, etc.) based on its content (610). As described above, at this step, the document capture server can examine the layout of the document and, from the layout, determine a class or type of the document. For instance, suppose the layout matches a credit card application form. Such a document can be considered as containing structured or semi-structured data and, as such, the document capture server can extract values from directly from the document and does not need additional data from an AI platform. In such cases (of structured/semi-structured documents), the document capture server can proceed to data validation (e.g., data integrity checks, user validation, etc.) without calling the AI platform." "[0071] Such a master document capture workflow or process flow may include workflow tasks such as determining a document type (e.g., from various types of documents such as invoices, purchase orders, contracts, complaints, forms, insurance claims, etc.), parsing text from the document, calling the AI platform with the parsed text (e.g., a block of text) and parameters specifying AI service(s) (e.g., a parameter for named entities such as people or organization names, or everything, in the block of text), receiving results from the AI platform (e.g., people names such as “Gareth,” organization names such as “Open Text,” etc.), determining whether the results are useful (e.g., whether “Gareth” and “Open Text” are relevant to the document type), and taking an appropriate action or causing an appropriate action to be taken (e.g., responsive to “Open Text” being relevant to the document type, adding “Open Text” as an organization for the document type or, responsive to “Open Text” not being relevant to the document type, removing “Open Text” as an organization from documents of the same type in the future, responsive to an indication of a car accident insurance claim, initiating a car accident insurance claim workflow, responsive to an indication of a customer complaint about a product, forwarding the customer complaint to a supervisor or customer service representative, responsive to a request for refund of overpayment, issuing a refund, etc.). Such actions can include those performed by the document capture server computer, a subsequent computing facility such as an ECM system, or a user.")
Hutchins does not explicitly teach, however, Guo does teach:
execute a content verification module to verify the extracted content based upon the document type of the document;
(Guo US20200211121 at paras. 61-66) ("[0061] For example, when the claim settlement materials including a payment invoice, an AI (Artificial Intelligence) technology may be used to identify the invoice information of the payment invoice, such as an invoice number, an invoice header, or a name of a payer. [0062] Based on the identified invoice information, the insurance platform can call an interface provided by a tax system to further authenticate the payment invoice. [0063] If the payment invoice is determined to be authentic, it can be determined that the payment invoice passes the authentication, and Step 210 may be performed. [0064] If the payment invoice is determined to be falsified, it can be determined that the payment invoice does not pass the authentication. The user is suspected of insurance fraud, and the credit platform can be notified to negatively update the credit information of the user. [0065] In another embodiment of the present specification, if the claim settlement materials include a proof of medical records, the AI technology may be used to identify whether the proof of medical records has a corresponding doctor's signature, or a hospital seal, etc. Identification can be made according to the requirements of proofs of real medical records. [0066] In an embodiment of the present specification, in addition to the AI technology, other technologies may also be used to authenticate the claim settlement materials, which are not limited by the present specification.")
in response to the extracted content being verified by the content verification module:
(Guo US20200211121 at paras. 61-66) ("[0061] For example, when the claim settlement materials including a payment invoice, an AI (Artificial Intelligence) technology may be used to identify the invoice information of the payment invoice, such as an invoice number, an invoice header, or a name of a payer. [0062] Based on the identified invoice information, the insurance platform can call an interface provided by a tax system to further authenticate the payment invoice. [0063] If the payment invoice is determined to be authentic, it can be determined that the payment invoice passes the authentication, and Step 210 may be performed. [0064] If the payment invoice is determined to be falsified, it can be determined that the payment invoice does not pass the authentication. The user is suspected of insurance fraud, and the credit platform can be notified to negatively update the credit information of the user. [0065] In another embodiment of the present specification, if the claim settlement materials include a proof of medical records, the AI technology may be used to identify whether the proof of medical records has a corresponding doctor's signature, or a hospital seal, etc. Identification can be made according to the requirements of proofs of real medical records. [0066] In an embodiment of the present specification, in addition to the AI technology, other technologies may also be used to authenticate the claim settlement materials, which are not limited by the present specification.")
indicating the extracted content was verified...
(Guo US20200211121 at paras. 61-66) ("[0062] Based on the identified invoice information, the insurance platform can call an interface provided by a tax system to further authenticate the payment invoice. [0063] If the payment invoice is determined to be authentic, it can be determined that the payment invoice passes the authentication, and Step 210 may be performed. [0064] If the payment invoice is determined to be falsified, it can be determined that the payment invoice does not pass the authentication. The user is suspected of insurance fraud, and the credit platform can be notified to negatively update the credit information of the user. [0065] In another embodiment of the present specification, if the claim settlement materials include a proof of medical records, the AI technology may be used to identify whether the proof of medical records has a corresponding doctor's signature, or a hospital seal, etc. Identification can be made according to the requirements of proofs of real medical records. [0066] In an embodiment of the present specification, in addition to the AI technology, other technologies may also be used to authenticate the claim settlement materials, which are not limited by the present specification.")
further process the incident report; and
(Guo US20200211121 at paras. 68-71) ("[0068] Based on the identification result in the above-described Step 208, if it is determined that the claim settlement materials pass the authentication, it can be determined that the claim settlement request is a real settlement request but not an insurance fraud. [0069] The claim settlement amount corresponding to the claim settlement material can be calculated. For example, an OCR (Optical Character Recognition) technology may be used to identify a payment amount in the payment invoice, and the corresponding claim settlement amount may be calculated accordingly. [0070] In an embodiment of the present specification, for a settlement of a medical insurance claim, categories (A, B, or C) and corresponding amounts of various expenses in the payment invoices can be identified based on the OCR technology. Then a corresponding claim settlement amount may be calculated based on the type of the medical insurance insured by the user. [0071] In another embodiment of the present specification, if the claim settlement type is a settlement of a mobile phone screen breakage insurance claim, a degree of screen breakage can also be identified based on an image processing technology. Then a corresponding claim settlement amount may be calculated according to the degree of screen breakage, which is not be elaborated in the present specification.")
in response to the extracted content not being verified by the content verification module: generate a denial indicator and
(Guo US20200211121 at paras. 61-66) ("[0064] If the payment invoice is determined to be falsified, it can be determined that the payment invoice does not pass the authentication. The user is suspected of insurance fraud, and the credit platform can be notified to negatively update the credit information of the user. [0065] In another embodiment of the present specification, if the claim settlement materials include a proof of medical records, the AI technology may be used to identify whether the proof of medical records has a corresponding doctor's signature, or a hospital seal, etc. Identification can be made according to the requirements of proofs of real medical records.")
indicating the incident report is denied…
(Guo US20200211121 at paras. 61-66) ("[0064] If the payment invoice is determined to be falsified, it can be determined that the payment invoice does not pass the authentication. The user is suspected of insurance fraud, and the credit platform can be notified to negatively update the credit information of the user. [0065] In another embodiment of the present specification, if the claim settlement materials include a proof of medical records, the AI technology may be used to identify whether the proof of medical records has a corresponding doctor's signature, or a hospital seal, etc. Identification can be made according to the requirements of proofs of real medical records.")
Therefore, it would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Hutchins and Guo, because it allows for an improved method for credit-based claim settlement. Also, claim settlement efficiency can be greatly enhanced, and claim settlement experience of the user can be improved. Claim settlement and smart online verification of the claim settlement materials can also protect interests of insurance companies and avoid financial losses caused by insurance fraud and other acts effectively. (Guo at Abstract and paras. 2-8).
Hutchins and Guo do not explicitly teach, however, Farmer does teach:
(ii) an identifier of the incident report, the incident report being stored within a database;
(Farmer US20210004909 at paras. 35-36) ("[0035] According to some embodiments, the mobile electronic device 302 and/or server 310 may identify the at least one data field 332-1, such as the “Policy Number” field of the insurance card 332, as depicted in FIG. 3. The mobile electronic device 302 may, for example, analyze an image of the insurance card 332 and apply image processing logic to identify the “Policy Number” characters and/or other indicia that indicates a desired area of information. In some embodiments, an offset rule (e.g., a rule specifying that characters adjacent to, such as below, the identified portion or header are to be captured) and/or other logic may be applied to identify and/or locate the field value 332-2, such as the policy number “010101234567”, as depicted. According to some embodiments, other fields, data, and/or indicia (e.g., human and/or computer-readable) may be utilized. In some embodiments, the field value 332-2 may be transmitted to the server 310 for verification and/or as the basis for an information query. The field value 332-2 may be utilized, for example, to query a database 340 in communication with the server 310 (and/or the mobile electronic device 302). According to some embodiments, the query may return data stored in association with the field value 332-2 (e.g., a particular insurance policy number, account, insured, etc.) and the mobile electronic device 302 may output (e.g., in response to a command from the server 310 including GUI generation instructions) some or all of such data as verification data 344 via the GUI 320 and/or display screen 318a. [0036] In some embodiments, the verification data 344 may comprise: (i) first verification data 344a such as a “policy number”; (ii) second verification data 344b such as a “vehicle” identifier; and/or (iii) third verification data 344c such as a “driver” identifier. According to some embodiments, the GUI 320 may comprise a verification checkbox element 344-1 that permits the user/insured to provide input indicating a verification of the policy number 344a (and/or to edit, correct, and/or enter different data). In some embodiments, the GUI 320 may comprise one or more drop-down menu elements 344-2a, 344-2b that permit the user/insured to provide input indicating a selection of one of a plurality of available data options. In the case of the vehicle 344b and the driver 344c, for example, the user/insured may utilize a first drop-down menu element 344-2a to view a listing of vehicles (and/or other objects; e.g., insured objects) associated with the policy number 344a in the database 340 and/or to select (and/or enter additional) one or more appropriate vehicles (and/or other objects), e.g., involved in an accident. Further, the user/insured may utilize a second drop-down menu element 344-2b to view a listing of drivers (or other individuals) associated with the policy number 344a in the database 340 and/or to select (and/or enter additional) one or more appropriate drivers/individuals, e.g., involved in an accident. In such a manner, for example, in the case that the information captured and identified from the insurance card 332 is accurate, a claim reporting application of the electronic mobile device 302 (and/or a web-based GUI 320 served by the server 310) may be pre-loaded with appropriate policy-related data (e.g., from the database 340) to both speed the entry/selection of the correct information, as well as to minimize potential errors (e.g., due to data entry mistakes, which may be particularly prevalent at an accident scene).")
linked to the incident report and the received identifier...
(Farmer US20210004909 at paras. 35-36) ("[0035] According to some embodiments, the mobile electronic device 302 and/or server 310 may identify the at least one data field 332-1, such as the “Policy Number” field of the insurance card 332, as depicted in FIG. 3. The mobile electronic device 302 may, for example, analyze an image of the insurance card 332 and apply image processing logic to identify the “Policy Number” characters and/or other indicia that indicates a desired area of information. In some embodiments, an offset rule (e.g., a rule specifying that characters adjacent to, such as below, the identified portion or header are to be captured) and/or other logic may be applied to identify and/or locate the field value 332-2, such as the policy number “010101234567”, as depicted. According to some embodiments, other fields, data, and/or indicia (e.g., human and/or computer-readable) may be utilized. In some embodiments, the field value 332-2 may be transmitted to the server 310 for verification and/or as the basis for an information query. The field value 332-2 may be utilized, for example, to query a database 340 in communication with the server 310 (and/or the mobile electronic device 302). According to some embodiments, the query may return data stored in association with the field value 332-2 (e.g., a particular insurance policy number, account, insured, etc.) and the mobile electronic device 302 may output (e.g., in response to a command from the server 310 including GUI generation instructions) some or all of such data as verification data 344 via the GUI 320 and/or display screen 318a. [0036] In some embodiments, the verification data 344 may comprise: (i) first verification data 344a such as a “policy number”; (ii) second verification data 344b such as a “vehicle” identifier; and/or (iii) third verification data 344c such as a “driver” identifier. According to some embodiments, the GUI 320 may comprise a verification checkbox element 344-1 that permits the user/insured to provide input indicating a verification of the policy number 344a (and/or to edit, correct, and/or enter different data). In some embodiments, the GUI 320 may comprise one or more drop-down menu elements 344-2a, 344-2b that permit the user/insured to provide input indicating a selection of one of a plurality of available data options. In the case of the vehicle 344b and the driver 344c, for example, the user/insured may utilize a first drop-down menu element 344-2a to view a listing of vehicles (and/or other objects; e.g., insured objects) associated with the policy number 344a in the database 340 and/or to select (and/or enter additional) one or more appropriate vehicles (and/or other objects), e.g., involved in an accident. Further, the user/insured may utilize a second drop-down menu element 344-2b to view a listing of drivers (or other individuals) associated with the policy number 344a in the database 340 and/or to select (and/or enter additional) one or more appropriate drivers/individuals, e.g., involved in an accident. In such a manner, for example, in the case that the information captured and identified from the insurance card 332 is accurate, a claim reporting application of the electronic mobile device 302 (and/or a web-based GUI 320 served by the server 310) may be pre-loaded with appropriate policy-related data (e.g., from the database 340) to both speed the entry/selection of the correct information, as well as to minimize potential errors (e.g., due to data entry mistakes, which may be particularly prevalent at an accident scene).")
transmit a response to the user computing device [indicating the extracted content was verified] and applied to the identified incident report; and
(Farmer US20210004909 at paras. 35-36) ("[0035] According to some embodiments, the mobile electronic device 302 and/or server 310 may identify the at least one data field 332-1, such as the “Policy Number” field of the insurance card 332, as depicted in FIG. 3. The mobile electronic device 302 may, for example, analyze an image of the insurance card 332 and apply image processing logic to identify the “Policy Number” characters and/or other indicia that indicates a desired area of information. In some embodiments, an offset rule (e.g., a rule specifying that characters adjacent to, such as below, the identified portion or header are to be captured) and/or other logic may be applied to identify and/or locate the field value 332-2, such as the policy number “010101234567”, as depicted. According to some embodiments, other fields, data, and/or indicia (e.g., human and/or computer-readable) may be utilized. In some embodiments, the field value 332-2 may be transmitted to the server 310 for verification and/or as the basis for an information query. The field value 332-2 may be utilized, for example, to query a database 340 in communication with the server 310 (and/or the mobile electronic device 302). According to some embodiments, the query may return data stored in association with the field value 332-2 (e.g., a particular insurance policy number, account, insured, etc.) and the mobile electronic device 302 may output (e.g., in response to a command from the server 310 including GUI generation instructions) some or all of such data as verification data 344 via the GUI 320 and/or display screen 318a. [0036] In some embodiments, the verification data 344 may comprise: (i) first verification data 344a such as a “policy number”; (ii) second verification data 344b such as a “vehicle” identifier; and/or (iii) third verification data 344c such as a “driver” identifier. According to some embodiments, the GUI 320 may comprise a verification checkbox element 344-1 that permits the user/insured to provide input indicating a verification of the policy number 344a (and/or to edit, correct, and/or enter different data). In some embodiments, the GUI 320 may comprise one or more drop-down menu elements 344-2a, 344-2b that permit the user/insured to provide input indicating a selection of one of a plurality of available data options. In the case of the vehicle 344b and the driver 344c, for example, the user/insured may utilize a first drop-down menu element 344-2a to view a listing of vehicles (and/or other objects; e.g., insured objects) associated with the policy number 344a in the database 340 and/or to select (and/or enter additional) one or more appropriate vehicles (and/or other objects), e.g., involved in an accident. Further, the user/insured may utilize a second drop-down menu element 344-2b to view a listing of drivers (or other individuals) associated with the policy number 344a in the database 340 and/or to select (and/or enter additional) one or more appropriate drivers/individuals, e.g., involved in an accident. In such a manner, for example, in the case that the information captured and identified from the insurance card 332 is accurate, a claim reporting application of the electronic mobile device 302 (and/or a web-based GUI 320 served by the server 310) may be pre-loaded with appropriate policy-related data (e.g., from the database 340) to both speed the entry/selection of the correct information, as well as to minimize potential errors (e.g., due to data entry mistakes, which may be particularly prevalent at an accident scene).")
linked to the incident report and the received identifier...
(Farmer US20210004909 at paras. 35-36) ("[0035] According to some embodiments, the mobile electronic device 302 and/or server 310 may identify the at least one data field 332-1, such as the “Policy Number” field of the insurance card 332, as depicted in FIG. 3. The mobile electronic device 302 may, for example, analyze an image of the insurance card 332 and apply image processing logic to identify the “Policy Number” characters and/or other indicia that indicates a desired area of information. In some embodiments, an offset rule (e.g., a rule specifying that characters adjacent to, such as below, the identified portion or header are to be captured) and/or other logic may be applied to identify and/or locate the field value 332-2, such as the policy number “010101234567”, as depicted. According to some embodiments, other fields, data, and/or indicia (e.g., human and/or computer-readable) may be utilized. In some embodiments, the field value 332-2 may be transmitted to the server 310 for verification and/or as the basis for an information query. The field value 332-2 may be utilized, for example, to query a database 340 in communication with the server 310 (and/or the mobile electronic device 302). According to some embodiments, the query may return data stored in association with the field value 332-2 (e.g., a particular insurance policy number, account, insured, etc.) and the mobile electronic device 302 may output (e.g., in response to a command from the server 310 including GUI generation instructions) some or all of such data as verification data 344 via the GUI 320 and/or display screen 318a. [0036] In some embodiments, the verification data 344 may comprise: (i) first verification data 344a such as a “policy number”; (ii) second verification data 344b such as a “vehicle” identifier; and/or (iii) third verification data 344c such as a “driver” identifier. According to some embodiments, the GUI 320 may comprise a verification checkbox element 344-1 that permits the user/insured to provide input indicating a verification of the policy number 344a (and/or to edit, correct, and/or enter different data). In some embodiments, the GUI 320 may comprise one or more drop-down menu elements 344-2a, 344-2b that permit the user/insured to provide input indicating a selection of one of a plurality of available data options. In the case of the vehicle 344b and the driver 344c, for example, the user/insured may utilize a first drop-down menu element 344-2a to view a listing of vehicles (and/or other objects; e.g., insured objects) associated with the policy number 344a in the database 340 and/or to select (and/or enter additional) one or more appropriate vehicles (and/or other objects), e.g., involved in an accident. Further, the user/insured may utilize a second drop-down menu element 344-2b to view a listing of drivers (or other individuals) associated with the policy number 344a in the database 340 and/or to select (and/or enter additional) one or more appropriate drivers/individuals, e.g., involved in an accident. In such a manner, for example, in the case that the information captured and identified from the insurance card 332 is accurate, a claim reporting application of the electronic mobile device 302 (and/or a web-based GUI 320 served by the server 310) may be pre-loaded with appropriate policy-related data (e.g., from the database 340) to both speed the entry/selection of the correct information, as well as to minimize potential errors (e.g., due to data entry mistakes, which may be particularly prevalent at an accident scene).")
transmit a response to the user computing device [indicating the incident report is denied] based upon the extracted content not being verified.
(Farmer US20210004909 at paras. 35-36) ("[0035] According to some embodiments, the mobile electronic device 302 and/or server 310 may identify the at least one data field 332-1, such as the “Policy Number” field of the insurance card 332, as depicted in FIG. 3. The mobile electronic device 302 may, for example, analyze an image of the insurance card 332 and apply image processing logic to identify the “Policy Number” characters and/or other indicia that indicates a desired area of information. In some embodiments, an offset rule (e.g., a rule specifying that characters adjacent to, such as below, the identified portion or header are to be captured) and/or other logic may be applied to identify and/or locate the field value 332-2, such as the policy number “010101234567”, as depicted. According to some embodiments, other fields, data, and/or indicia (e.g., human and/or computer-readable) may be utilized. In some embodiments, the field value 332-2 may be transmitted to the server 310 for verification and/or as the basis for an information query. The field value 332-2 may be utilized, for example, to query a database 340 in communication with the server 310 (and/or the mobile electronic device 302). According to some embodiments, the query may return data stored in association with the field value 332-2 (e.g., a particular insurance policy number, account, insured, etc.) and the mobile electronic device 302 may output (e.g., in response to a command from the server 310 including GUI generation instructions) some or all of such data as verification data 344 via the GUI 320 and/or display screen 318a. [0036] In some embodiments, the verification data 344 may comprise: (i) first verification data 344a such as a “policy number”; (ii) second verification data 344b such as a “vehicle” identifier; and/or (iii) third verification data 344c such as a “driver” identifier. According to some embodiments, the GUI 320 may comprise a verification checkbox element 344-1 that permits the user/insured to provide input indicating a verification of the policy number 344a (and/or to edit, correct, and/or enter different data). In some embodiments, the GUI 320 may comprise one or more drop-down menu elements 344-2a, 344-2b that permit the user/insured to provide input indicating a selection of one of a plurality of available data options. In the case of the vehicle 344b and the driver 344c, for example, the user/insured may utilize a first drop-down menu element 344-2a to view a listing of vehicles (and/or other objects; e.g., insured objects) associated with the policy number 344a in the database 340 and/or to select (and/or enter additional) one or more appropriate vehicles (and/or other objects), e.g., involved in an accident. Further, the user/insured may utilize a second drop-down menu element 344-2b to view a listing of drivers (or other individuals) associated with the policy number 344a in the database 340 and/or to select (and/or enter additional) one or more appropriate drivers/individuals, e.g., involved in an accident. In such a manner, for example, in the case that the information captured and identified from the insurance card 332 is accurate, a claim reporting application of the electronic mobile device 302 (and/or a web-based GUI 320 served by the server 310) may be pre-loaded with appropriate policy-related data (e.g., from the database 340) to both speed the entry/selection of the correct information, as well as to minimize potential errors (e.g., due to data entry mistakes, which may be particularly prevalent at an accident scene).")
Therefore, it would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Hutchins, Guo, and Farmer, because it allows for an improved method for real-time accident analysis that provide for in-process user guidance for incident image documentation, recorded statements, and user-drawn scene diagramming via a mobile device GUI vector and map-based drawing tool. (Farmer at Abstract and paras. 1-14).
Hutchins, Guo, and Farmer do not explicitly teach, however, Tsai does teach:
update the incident report by storing the extracted content within the database linked to the incident report and [the received identifier];
(Tsai US20200192862 at paras. 24-26) ("[0025] Referring back to FIG. 1, the system 108 may receive a file from one of the sources 102, 104, and/or 106 and may store the file in the data storage 118. The file may be in any one of multiple different file types and may include healthcare related information, such as insurance claims information, patient data, medical claim data, pharmacy claim data, clinical data, financial data, data from The Centers for Medicare and Medicaid Services (CMS), prescription data, etc. The parser component 120 may identify a file type associated with the file based at least in part on a source of the file and/or metadata associated with the file. For example, the parser component 120 may determine a file type of the file by, by way of example, performing a regex search on the file in order to identify a sequence of characters or a pattern that matches a predetermined category. Each parser may be associated with at least one of the predetermined categories and/or a regex category and the parser component 120 may then select the appropriate parser to be used to extract the usable data in the file based on the category in which the file is associated with and the associated parser. Selecting the appropriate parser, by the parser component 120, allows the parser to automatically extract the usable data from the file without the need for a user to do so manually. In some cases, the parser component 120 may determine that a certain type of data matches a type of data that was previously extracted. For example, the parser component 120 may determine that the data includes updated insurance claims data from a particular source and that the updated insurance claims data matches previously received insurance claims data from the same source. In this case, the parser component 120 may update a value that represents the insurance claims data associated with the source to reflect the updated insurance claims data. In some cases, the parsed data may be stored as tables and stored in the data storage 118. Once the data from the file has been parsed, the system 108 may receive instructions from a user 128 via a computing device 130 to perform a transformation on the data. The transformation component 122 may store multiple different types of transformations that can be performed on the data, such as merging data, filtering data, and/or de-duplication of pieces of data. The transformation component 122 may receive a selection from the user 128 via the computing device 130 of inputs to be incorporated in the transformation. The inputs may include a table representative of the different data sets extracted from the file by the parser component 120. The transformation component 122 may provide an output in the form of a table that includes the result of the transformation of the input. The pipeline component 126 may generate a dependency graph that links multiple transformations. For example, the input of a transformation may depend on the output of a previous transformation, forming a pipeline of dependent transformations that originates from the file received by the sources 102, 104, and/or 106. Once a pipeline has been established, the monitoring component 124 may compare the row number, column number, and/or the values of subsequently received files to previously received files containing the same or similar types of information. If the monitoring component 124 determines that there is an error contained in the files, then the monitoring component 124 may send a notification to a user associated with the system 108 (e.g., a data scientist, engineer, etc.) indicating that an error is present.")
update the incident report by storing the denial indicator within the database linked to the incident report and [the received identifier]; and
(Tsai US20200192862 at paras. 24-26) ("[0025] Referring back to FIG. 1, the system 108 may receive a file from one of the sources 102, 104, and/or 106 and may store the file in the data storage 118. The file may be in any one of multiple different file types and may include healthcare related information, such as insurance claims information, patient data, medical claim data, pharmacy claim data, clinical data, financial data, data from The Centers for Medicare and Medicaid Services (CMS), prescription data, etc. The parser component 120 may identify a file type associated with the file based at least in part on a source of the file and/or metadata associated with the file. For example, the parser component 120 may determine a file type of the file by, by way of example, performing a regex search on the file in order to identify a sequence of characters or a pattern that matches a predetermined category. Each parser may be associated with at least one of the predetermined categories and/or a regex category and the parser component 120 may then select the appropriate parser to be used to extract the usable data in the file based on the category in which the file is associated with and the associated parser. Selecting the appropriate parser, by the parser component 120, allows the parser to automatically extract the usable data from the file without the need for a user to do so manually. In some cases, the parser component 120 may determine that a certain type of data matches a type of data that was previously extracted. For example, the parser component 120 may determine that the data includes updated insurance claims data from a particular source and that the updated insurance claims data matches previously received insurance claims data from the same source. In this case, the parser component 120 may update a value that represents the insurance claims data associated with the source to reflect the updated insurance claims data. In some cases, the parsed data may be stored as tables and stored in the data storage 118. Once the data from the file has been parsed, the system 108 may receive instructions from a user 128 via a computing device 130 to perform a transformation on the data. The transformation component 122 may store multiple different types of transformations that can be performed on the data, such as merging data, filtering data, and/or de-duplication of pieces of data. The transformation component 122 may receive a selection from the user 128 via the computing device 130 of inputs to be incorporated in the transformation. The inputs may include a table representative of the different data sets extracted from the file by the parser component 120. The transformation component 122 may provide an output in the form of a table that includes the result of the transformation of the input. The pipeline component 126 may generate a dependency graph that links multiple transformations. For example, the input of a transformation may depend on the output of a previous transformation, forming a pipeline of dependent transformations that originates from the file received by the sources 102, 104, and/or 106. Once a pipeline has been established, the monitoring component 124 may compare the row number, column number, and/or the values of subsequently received files to previously received files containing the same or similar types of information. If the monitoring component 124 determines that there is an error contained in the files, then the monitoring component 124 may send a notification to a user associated with the system 108 (e.g., a data scientist, engineer, etc.) indicating that an error is present.")
Therefore, it would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Hutchins, Guo, Farmer, and Tsai, because it allows for improved methods to generate data sets of sufficient quantity and quality to increase the accuracy of data analytics. (Tsai at Abstract and paras. 1-12).
As per claim 2,
Hutchins does not explicitly teach, however, Guo does teach:
(b) vehicle repair invoice, and (c) medical care invoice.
(Guo US20200211121 at paras. 19-21) ("[0019] The claim settlement request may be, but not limited to, a settlement request for a medical insurance claim, a settlement request for a mobile phone screen breakage insurance claim, a settlement request for a car insurance claim, or the like. [0020] In step 104, when the credit information of the user satisfies a credit constraint condition, the user is prompted to upload claim settlement materials. [0021] The claim settlement materials may be uploaded by the user who initiates the claim settlement request, and may include a photo of a payment invoice, a picture of an accident, or the like." "[0061] For example, when the claim settlement materials including a payment invoice, an AI (Artificial Intelligence) technology may be used to identify the invoice information of the payment invoice, such as an invoice number, an invoice header, or a name of a payer." "[0065] In another embodiment of the present specification, if the claim settlement materials include a proof of medical records, the AI technology may be used to identify whether the proof of medical records has a corresponding doctor's signature, or a hospital seal, etc. Identification can be made according to the requirements of proofs of real medical records.")
Therefore, it would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Hutchins and Guo, because it allows for an improved method for credit-based claim settlement. Also, claim settlement efficiency can be greatly enhanced, and claim settlement experience of the user can be improved. Claim settlement and smart online verification of the claim settlement materials can also protect interests of insurance companies and avoid financial losses caused by insurance fraud and other acts effectively. (Guo at Abstract and paras. 2-8).
Hutchins and Guo do not explicitly teach, however, Farmer does teach:
wherein the plurality of document types include at least: (a) driver's license,
(Farmer US20210004909 at paras. 27-29, 35-36) ("[0027] In some embodiments, the mobile electronic device 202a (and/or the input devices 216a-b thereof) may capture, sense, record, and/or be triggered by objects, data, and/or signals at or near an accident scene (e.g., the depicted setting of the system 200 in FIG. 2). The camera 216a of the mobile electronic device 202a may, for example, capture images (e.g., in response to image capture guidance and/or rules) of one or more textual indicia 232a-b within visual proximity to the mobile electronic device 202a. At the accident scene, for example, the camera 216a may capture an image (and/or video) of an identification card, such as the depicted vehicle operator's license 232a (e.g., a driver's license and/or other identification card, such as an insurance card), and/or an identifier of the vehicle 202b, such as the depicted license plate number 232b (e.g., a Vehicle Identification Number (VIN), make, model, and/or other human or computer-readable indicia).")
Therefore, it would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Hutchins, Guo, Farmer, and Tsai, because it allows for an improved method for real-time accident analysis that provide for in-process user guidance for incident image documentation, recorded statements, and user-drawn scene diagramming via a mobile device GUI vector and map-based drawing tool. (Farmer at Abstract and paras. 1-14).
As per claim 6,
Hutchins explicitly teaches:
wherein the document classification model is an artificial intelligence-based model that includes at least one of a conditional neural network optical character recognition (OCR) model, a long short term memory OCR model, and a template matching model.
(Hutchins US20200210490 at paras. 3-10, 33-45) ("[0003] An object of the invention is to change the division of labor in processing captured documents by leveraging artificial intelligence (AI) to enhance document capture and to provide insight on unstructured data before providing the captured documents to a downstream computing facility such as a content management system operating in an enterprise computing environment. [0004] Generally, this object can be achieved in a document capture server computer that can import/capture/ingest documents, convert them to appropriate format(s), enhance the documents, and apply optical character recognition (OCR) to the documents. Additionally, the document capture server computer can determine their graphical layouts respectively, extract keywords contained in the documents, and classify the documents based on their respective graphical layouts and/or extracted keywords." "[0033] Likewise, the document capture server computer can analyze a document, identify keywords in the document, extract those keywords from the document, and determine a class for the document based on the keywords extracted from the document. At this processing stage (e.g., document classification and extraction stage 224), the document capture server computer can perform other document analyses such as zonal extraction and freeform extraction for certain types of documents (e.g., documents with forms, documents with regular expressions), etc. Zonal extraction, also referred to as template OCR, can extract text located at a specific location or zone within a document.")
Claims 11 and 18 are substantially similar to claim 1, thus, they are rejected on similar grounds.
Claim 19 is substantially similar to claim 6, thus, it is rejected on similar grounds.
Claims 3-5 and 12-14 are rejected under 35 U.S.C. 103 as being unpatentable over Hutchins, U.S. Patent Application Publication Number 2020/0210490; in view of Guo, U.S. Patent Application Publication Number 2020/0211121; in view of Farmer, U.S. Patent Application Publication Number 2021/0004909; in view of Tsai, U.S. Patent Application Publication Number 2020/0192862; in view of Neelamana, U.S. Patent Application Publication Number 2020/0143257.
As per claim 3,
Hutchins and Guo do not explicitly teach, however, Farmer does teach:
driver's license document content...
(Farmer US20210004909 at paras. 27-29, 35-36) ("[0027] In some embodiments, the mobile electronic device 202a (and/or the input devices 216a-b thereof) may capture, sense, record, and/or be triggered by objects, data, and/or signals at or near an accident scene (e.g., the depicted setting of the system 200 in FIG. 2). The camera 216a of the mobile electronic device 202a may, for example, capture images (e.g., in response to image capture guidance and/or rules) of one or more textual indicia 232a-b within visual proximity to the mobile electronic device 202a. At the accident scene, for example, the camera 216a may capture an image (and/or video) of an identification card, such as the depicted vehicle operator's license 232a (e.g., a driver's license and/or other identification card, such as an insurance card), and/or an identifier of the vehicle 202b, such as the depicted license plate number 232b (e.g., a Vehicle Identification Number (VIN), make, model, and/or other human or computer-readable indicia).")
Therefore, it would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Hutchins, Guo, and Farmer, because it allows for an improved method for real-time accident analysis that provide for in-process user guidance for incident image documentation, recorded statements, and user-drawn scene diagramming via a mobile device GUI vector and map-based drawing tool. (Farmer at Abstract and paras. 1-14).
Hutchins, Guo, Farmer, and Tsai do not explicitly teach, however, Neelamana does teach:
wherein the at least one processor is further programmed to: store, in the at least one memory device, a training set of [driver's license document] content; execute a training module to train the classification module based upon the training set of [driver's license document] content; and build the document classification model based upon the training.
(Neelamana US20200143257 at paras. 30-31, 46-47, 50-52) ("[0031] Additional seed datasets may be generated from a corpus of electronic documents. This is done, for example, by training the seed dataset generator with additional words and phrases from the corpus of electronic documents. Additional domain-specific information can be added to domain-specific dictionaries and domain-specific ontologies based on the additional seed datasets. The domain-specific dictionaries and domain-specific ontologies can be systematically updated when, for example, new concepts, words, and/or phrases are uncovered through processing documents. For example, in the domain of insurance, insurance terminology and classifications can be added to update insurance semantics dictionaries and an insurance ontology using one or more seed datasets obtained from a corpus of electronic documents related to insurance. Then, a machine learning algorithm can be trained or re-trained using the additional seed datasets, the updated insurance semantic dictionaries and the updated insurance ontology. After training or re-training, the machine learning algorithm may be used again identify insurance documents, extract, and classify data from a corpus of documents and monitor performance. The herein-described machine-learning algorithm may be re-trained using new seed datasets or updating the insurance semantic dictionaries and insurance ontology until the desired performance is reached. The criteria to reach a desired performance can include a confidence level for the extracted, categorized, and classified data. The criteria can also include user feedback through the graphical user interface. Additionally, the confidence level can relate to a level of an ability of a machine-learning algorithm to accurately recognize a concept and map that concept to an ontology and/or a level of an ability of the machine-learning algorithm accurately translate the ontology to execute business rules For example, performance can be achieved when accuracy of the machine learning algorithm is at least a same level of accuracy as a human reviewer on at least a predetermined percentage (e.g., 75%, 80%, 90%, 95%) of the documents. Once the desired performance is reached with insurance documents identified and the relevant data classified to an insurance ontology, the information may be stored and manipulated for various purposes.")
Therefore, it would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Hutchins, Guo, Farmer, Tsai, and Neelamana, because it allows for improved methods to efficiently and accurately read electronic documents included in a corpus of electronic documents, categorize the documents, and classify the data in accordance with, for example, the ontology of a domain. (Neelamana at Abstract and paras. 27-29).
As per claim 4,
Hutchins does not explicitly teach, however, Guo does teach:
vehicle repair invoice document content...
(Guo US20200211121 at paras. 19-21) ("[0019] The claim settlement request may be, but not limited to, a settlement request for a medical insurance claim, a settlement request for a mobile phone screen breakage insurance claim, a settlement request for a car insurance claim, or the like. [0020] In step 104, when the credit information of the user satisfies a credit constraint condition, the user is prompted to upload claim settlement materials. [0021] The claim settlement materials may be uploaded by the user who initiates the claim settlement request, and may include a photo of a payment invoice, a picture of an accident, or the like." "[0061] For example, when the claim settlement materials including a payment invoice, an AI (Artificial Intelligence) technology may be used to identify the invoice information of the payment invoice, such as an invoice number, an invoice header, or a name of a payer." "[0065] In another embodiment of the present specification, if the claim settlement materials include a proof of medical records, the AI technology may be used to identify whether the proof of medical records has a corresponding doctor's signature, or a hospital seal, etc. Identification can be made according to the requirements of proofs of real medical records.")
Therefore, it would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Hutchins and Guo, because it allows for an improved method for credit-based claim settlement. Also, claim settlement efficiency can be greatly enhanced, and claim settlement experience of the user can be improved. Claim settlement and smart online verification of the claim settlement materials can also protect interests of insurance companies and avoid financial losses caused by insurance fraud and other acts effectively. (Guo at Abstract and paras. 2-8).
Hutchins, Guo, Farmer, and Tsai do not explicitly teach, however, Neelamana does teach:
wherein the at least one processor is further programmed to: store, in the at least one memory device, a training set of [vehicle repair invoice document] content; execute a training module to train the classification module based upon the training set of [vehicle repair invoice document] content; and build the document classification model based upon the training.
(Neelamana US20200143257 at paras. 30-31, 46-47, 50-52) ("[0031] Additional seed datasets may be generated from a corpus of electronic documents. This is done, for example, by training the seed dataset generator with additional words and phrases from the corpus of electronic documents. Additional domain-specific information can be added to domain-specific dictionaries and domain-specific ontologies based on the additional seed datasets. The domain-specific dictionaries and domain-specific ontologies can be systematically updated when, for example, new concepts, words, and/or phrases are uncovered through processing documents. For example, in the domain of insurance, insurance terminology and classifications can be added to update insurance semantics dictionaries and an insurance ontology using one or more seed datasets obtained from a corpus of electronic documents related to insurance. Then, a machine learning algorithm can be trained or re-trained using the additional seed datasets, the updated insurance semantic dictionaries and the updated insurance ontology. After training or re-training, the machine learning algorithm may be used again identify insurance documents, extract, and classify data from a corpus of documents and monitor performance. The herein-described machine-learning algorithm may be re-trained using new seed datasets or updating the insurance semantic dictionaries and insurance ontology until the desired performance is reached. The criteria to reach a desired performance can include a confidence level for the extracted, categorized, and classified data. The criteria can also include user feedback through the graphical user interface. Additionally, the confidence level can relate to a level of an ability of a machine-learning algorithm to accurately recognize a concept and map that concept to an ontology and/or a level of an ability of the machine-learning algorithm accurately translate the ontology to execute business rules For example, performance can be achieved when accuracy of the machine learning algorithm is at least a same level of accuracy as a human reviewer on at least a predetermined percentage (e.g., 75%, 80%, 90%, 95%) of the documents. Once the desired performance is reached with insurance documents identified and the relevant data classified to an insurance ontology, the information may be stored and manipulated for various purposes.")
Therefore, it would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Hutchins, Guo, Farmer, Tsai, and Neelamana, because it allows for improved methods to efficiently and accurately read electronic documents included in a corpus of electronic documents, categorize the documents, and classify the data in accordance with, for example, the ontology of a domain. (Neelamana at Abstract and paras. 27-29).
As per claim 5,
Hutchins does not explicitly teach, however, Guo does teach:
medical care invoice document content
(Guo US20200211121 at paras. 19-21) ("[0019] The claim settlement request may be, but not limited to, a settlement request for a medical insurance claim, a settlement request for a mobile phone screen breakage insurance claim, a settlement request for a car insurance claim, or the like. [0020] In step 104, when the credit information of the user satisfies a credit constraint condition, the user is prompted to upload claim settlement materials. [0021] The claim settlement materials may be uploaded by the user who initiates the claim settlement request, and may include a photo of a payment invoice, a picture of an accident, or the like." "[0061] For example, when the claim settlement materials including a payment invoice, an AI (Artificial Intelligence) technology may be used to identify the invoice information of the payment invoice, such as an invoice number, an invoice header, or a name of a payer." "[0065] In another embodiment of the present specification, if the claim settlement materials include a proof of medical records, the AI technology may be used to identify whether the proof of medical records has a corresponding doctor's signature, or a hospital seal, etc. Identification can be made according to the requirements of proofs of real medical records.")
Therefore, it would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Hutchins and Guo, because it allows for an improved method for credit-based claim settlement. Also, claim settlement efficiency can be greatly enhanced, and claim settlement experience of the user can be improved. Claim settlement and smart online verification of the claim settlement materials can also protect interests of insurance companies and avoid financial losses caused by insurance fraud and other acts effectively. (Guo at Abstract and paras. 2-8).
Hutchins, Guo, Farmer, and Tsai do not explicitly teach, however, Neelamana does teach:
wherein the at least one processor is further programmed to: store, in the at least one memory device, a training set of [medical care invoice document] content; execute a training module to train the classification module based upon the training set of [medical care invoice document] content; and build the document classification model based upon the training.
(Neelamana US20200143257 at paras. 30-31, 46-47, 50-52) ("[0031] Additional seed datasets may be generated from a corpus of electronic documents. This is done, for example, by training the seed dataset generator with additional words and phrases from the corpus of electronic documents. Additional domain-specific information can be added to domain-specific dictionaries and domain-specific ontologies based on the additional seed datasets. The domain-specific dictionaries and domain-specific ontologies can be systematically updated when, for example, new concepts, words, and/or phrases are uncovered through processing documents. For example, in the domain of insurance, insurance terminology and classifications can be added to update insurance semantics dictionaries and an insurance ontology using one or more seed datasets obtained from a corpus of electronic documents related to insurance. Then, a machine learning algorithm can be trained or re-trained using the additional seed datasets, the updated insurance semantic dictionaries and the updated insurance ontology. After training or re-training, the machine learning algorithm may be used again identify insurance documents, extract, and classify data from a corpus of documents and monitor performance. The herein-described machine-learning algorithm may be re-trained using new seed datasets or updating the insurance semantic dictionaries and insurance ontology until the desired performance is reached. The criteria to reach a desired performance can include a confidence level for the extracted, categorized, and classified data. The criteria can also include user feedback through the graphical user interface. Additionally, the confidence level can relate to a level of an ability of a machine-learning algorithm to accurately recognize a concept and map that concept to an ontology and/or a level of an ability of the machine-learning algorithm accurately translate the ontology to execute business rules For example, performance can be achieved when accuracy of the machine learning algorithm is at least a same level of accuracy as a human reviewer on at least a predetermined percentage (e.g., 75%, 80%, 90%, 95%) of the documents. Once the desired performance is reached with insurance documents identified and the relevant data classified to an insurance ontology, the information may be stored and manipulated for various purposes.")
Therefore, it would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Hutchins, Guo, Farmer, Tsai, and Neelamana, because it allows for improved methods to efficiently and accurately read electronic documents included in a corpus of electronic documents, categorize the documents, and classify the data in accordance with, for example, the ontology of a domain. (Neelamana at Abstract and paras. 27-29).
Claims 12-14 are substantially similar to claims 3-5, thus, they are rejected on similar grounds.
Claims 7 and 15 are rejected under 35 U.S.C. 103 as being unpatentable over Hutchins, U.S. Patent Application Publication Number 2020/0210490; in view of Guo, U.S. Patent Application Publication Number 2020/0211121; in view of Farmer, U.S. Patent Application Publication Number 2021/0004909; in view of Tsai, U.S. Patent Application Publication Number 2020/0192862; in view of Wang, WIPO Patent Application Publication Number 2017/124990.
As per claim 7,
Hutchins and Guo do not explicitly teach, however, Farmer does teach:
wherein the document type is driver's license, and
(Farmer US20210004909 at paras. 27-29, 35-36) ("[0027] In some embodiments, the mobile electronic device 202a (and/or the input devices 216a-b thereof) may capture, sense, record, and/or be triggered by objects, data, and/or signals at or near an accident scene (e.g., the depicted setting of the system 200 in FIG. 2). The camera 216a of the mobile electronic device 202a may, for example, capture images (e.g., in response to image capture guidance and/or rules) of one or more textual indicia 232a-b within visual proximity to the mobile electronic device 202a. At the accident scene, for example, the camera 216a may capture an image (and/or video) of an identification card, such as the depicted vehicle operator's license 232a (e.g., a driver's license and/or other identification card, such as an insurance card), and/or an identifier of the vehicle 202b, such as the depicted license plate number 232b (e.g., a Vehicle Identification Number (VIN), make, model, and/or other human or computer-readable indicia).")
Therefore, it would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Hutchins, Guo, and Farmer, because it allows for an improved method for real-time accident analysis that provide for in-process user guidance for incident image documentation, recorded statements, and user-drawn scene diagramming via a mobile device GUI vector and map-based drawing tool. (Farmer at Abstract and paras. 1-14).
Hutchins, Guo, Farmer, and Tsai do not explicitly teach, however, Wang does teach:
wherein executing the content verification module to verify the extracted content comprises performing at least one of (a) key point matching based upon the extracted content and stored data associated with the user, and (b) fake/real classification.
(Wang WO2017124990A1 at pp. 6-7, 10-12) ("In view of the above, it is necessary to provide a method, system, device and readable storage medium for implementing insurance claims anti-fraud based on multiple picture consistency, which can automatically identify fraudulent claims behavior. A method for implementing insurance claims anti-fraud based on multiple image consistency, the method comprising: Receiving a plurality of fixed-loss photos of the vehicle photographed from different shooting angles uploaded by the user through the terminal; Using an analysis model, analyzing the vehicle parts corresponding to each fixed-loss photo, and classifying the fixed-loss photos to divide the fixed-loss photos of the same vehicle parts into the same photo collection; Performing key point detection on the fixed loss photos in each photo collection, and obtaining key point features of the vehicle parts corresponding to the respective photo collections; The fixed-loss photos of the respective photo collections are respectively grouped into two groups, and according to a key point matching algorithm, the key points corresponding to the respective sets are matched with the photos in the respective groups of the set, and the key points are matched in each group. The loss photos respectively match at least one set of related key points; According to the relevant key points corresponding to each group, a linear equation is used to calculate a feature point transformation matrix corresponding to each group, and a corresponding feature point transformation matrix is used to convert one of the photos in each group into another group with the group. The photo to be verified with the same shooting angle; Matching the to-be-verified photo with another photo in the group; and When the feature to be verified does not match the feature parameter of another photo in the group, a reminder message is generated to remind the received picture that there is fraudulent behavior." "In step S00, the model training module 100 acquires a preset number of photos of various parts of the vehicle from a car insurance claim database. In this embodiment, the model training module 100 classifies according to a preset part of the vehicle (for example, the vehicle preset part classification includes a front side, a side, a tail, a whole, and the like), and the vehicle insurance claim database (for example, the automobile insurance) The claim database stores a mapping relationship or tag data of a predetermined part classification of the vehicle and a fixed-loss photo, and the fixed-loss photo refers to a photo taken by the repair shop at the time of the fixed damage) A preset number of presets (for example, 100,000 sheets) (for example, a photo taken in front of 100,000 cars).")
Therefore, it would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Hutchins, Guo, Farmer, Tsai, and Wang, because it allows for improved methods for implementing insurance claims anti-fraud based on multiple picture consistency, which can automatically identify fraudulent claims behavior. (Wang at Abstract and pp. 6-7).
Claim 15 is substantially similar to claim 7, thus, it is rejected on similar grounds.
Claims 8 and 9 are rejected under 35 U.S.C. 103 as being unpatentable over Hutchins, U.S. Patent Application Publication Number 2020/0210490; in view of Guo, U.S. Patent Application Publication Number 2020/0211121; in view of Farmer, U.S. Patent Application Publication Number 2021/0004909; in view of Tsai, U.S. Patent Application Publication Number 2020/0192862; in view of Neelamana, U.S. Patent Application Publication Number 2020/0143257; in view of Matyska, U.S. Patent Application Publication Number 2020/0334228.
As per claim 8,
Hutchins does not explicitly teach, however, Guo does teach:
wherein the incident report includes an insurance claim submitted by a policyholder and associated with an accident, and
(Guo US20200211121 at paras. 61-66) ("[0061] For example, when the claim settlement materials including a payment invoice, an AI (Artificial Intelligence) technology may be used to identify the invoice information of the payment invoice, such as an invoice number, an invoice header, or a name of a payer. [0062] Based on the identified invoice information, the insurance platform can call an interface provided by a tax system to further authenticate the payment invoice. [0063] If the payment invoice is determined to be authentic, it can be determined that the payment invoice passes the authentication, and Step 210 may be performed. [0064] If the payment invoice is determined to be falsified, it can be determined that the payment invoice does not pass the authentication. The user is suspected of insurance fraud, and the credit platform can be notified to negatively update the credit information of the user. [0065] In another embodiment of the present specification, if the claim settlement materials include a proof of medical records, the AI technology may be used to identify whether the proof of medical records has a corresponding doctor's signature, or a hospital seal, etc. Identification can be made according to the requirements of proofs of real medical records. [0066] In an embodiment of the present specification, in addition to the AI technology, other technologies may also be used to authenticate the claim settlement materials, which are not limited by the present specification.")
wherein the document type is a vehicle repair invoice, and
(Guo US20200211121 at paras. 19-21) ("[0019] The claim settlement request may be, but not limited to, a settlement request for a medical insurance claim, a settlement request for a mobile phone screen breakage insurance claim, a settlement request for a car insurance claim, or the like. [0020] In step 104, when the credit information of the user satisfies a credit constraint condition, the user is prompted to upload claim settlement materials. [0021] The claim settlement materials may be uploaded by the user who initiates the claim settlement request, and may include a photo of a payment invoice, a picture of an accident, or the like." "[0061] For example, when the claim settlement materials including a payment invoice, an AI (Artificial Intelligence) technology may be used to identify the invoice information of the payment invoice, such as an invoice number, an invoice header, or a name of a payer." "[0065] In another embodiment of the present specification, if the claim settlement materials include a proof of medical records, the AI technology may be used to identify whether the proof of medical records has a corresponding doctor's signature, or a hospital seal, etc. Identification can be made according to the requirements of proofs of real medical records.")
based upon the extracted content and stored historical vehicle repair invoice data, and
(Guo US20200211121 at paras. 19-21) ("[0019] The claim settlement request may be, but not limited to, a settlement request for a medical insurance claim, a settlement request for a mobile phone screen breakage insurance claim, a settlement request for a car insurance claim, or the like. [0020] In step 104, when the credit information of the user satisfies a credit constraint condition, the user is prompted to upload claim settlement materials. [0021] The claim settlement materials may be uploaded by the user who initiates the claim settlement request, and may include a photo of a payment invoice, a picture of an accident, or the like." "[0061] For example, when the claim settlement materials including a payment invoice, an AI (Artificial Intelligence) technology may be used to identify the invoice information of the payment invoice, such as an invoice number, an invoice header, or a name of a payer." "[0065] In another embodiment of the present specification, if the claim settlement materials include a proof of medical records, the AI technology may be used to identify whether the proof of medical records has a corresponding doctor's signature, or a hospital seal, etc. Identification can be made according to the requirements of proofs of real medical records.")
the vehicle repair invoice…
(Guo US20200211121 at paras. 19-21) ("[0019] The claim settlement request may be, but not limited to, a settlement request for a medical insurance claim, a settlement request for a mobile phone screen breakage insurance claim, a settlement request for a car insurance claim, or the like. [0020] In step 104, when the credit information of the user satisfies a credit constraint condition, the user is prompted to upload claim settlement materials. [0021] The claim settlement materials may be uploaded by the user who initiates the claim settlement request, and may include a photo of a payment invoice, a picture of an accident, or the like." "[0061] For example, when the claim settlement materials including a payment invoice, an AI (Artificial Intelligence) technology may be used to identify the invoice information of the payment invoice, such as an invoice number, an invoice header, or a name of a payer." "[0065] In another embodiment of the present specification, if the claim settlement materials include a proof of medical records, the AI technology may be used to identify whether the proof of medical records has a corresponding doctor's signature, or a hospital seal, etc. Identification can be made according to the requirements of proofs of real medical records.")
Therefore, it would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Hutchins and Guo, because it allows for an improved method for credit-based claim settlement. Also, claim settlement efficiency can be greatly enhanced, and claim settlement experience of the user can be improved. Claim settlement and smart online verification of the claim settlement materials can also protect interests of insurance companies and avoid financial losses caused by insurance fraud and other acts effectively. (Guo at Abstract and paras. 2-8).
Hutchins, Guo, Farmer, and Tsai do not explicitly teach, however, Neelamana does teach:
(ii) causing a graphical user interface to be displayed on an administrator computing device
(Neelamana US20200143257 at paras. 50-51) ("[0050] The GUI generator 408 can include a user interface that generates a display for the administrator to interact with the system (e.g., as discussed in the context of at least FIG. 12-15). The API server 409 can be an interface between the GUI generator 408 and the display 410. The display 410 can show the user interface generated by the GUI generator 408 to the administrator (e.g., as discussed in the context of at least FIG. 12-15)." )
Therefore, it would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Hutchins, Guo, Farmer, Tsai, and Neelamana, because it allows for improved methods to efficiently and accurately read electronic documents included in a corpus of electronic documents, categorize the documents, and classify the data in accordance with, for example, the ontology of a domain. (Neelamana at Abstract and paras. 27-29).
Hutchins, Guo, Farmer, Tsai, and Neelamana do not explicitly teach, however, Matyska does teach:
wherein executing the content verification module to verify the extracted content further comprises (i) performing anomaly detection
(Matyska US20200334228 at paras. 36-46) ("[0036] In one embodiment of the invention, the system or the operational system handles records that concern insurance claims. In this context, it is assumed that an insurance company may require said system or said operational system for processing and analysis of data regarding insurance claims and payout of insurance claims. The system and operational system may be multi-layered, wherein data is received from claimants, health care providers, medical professionals, diagnostic persons, as well as, internal processing by members of the insurance company. The data present in the record of the insurance claim typically undergoes processing and analysis with established business rules of the insurance company. In this context, the “user” providing an insurance claim may in one embodiment be the claimant, but may as well be anyone involved in the processing of the claim. The “operator” on the other hand is typically someone from the insurance company, but may also concern a third party responsible for performing fraud detection on insurance claims. [0037] In a first aspect, the present invention provides a system for detecting anomalies, said system comprising [0038] a communication module having access to a database comprising a plurality of physical entity records, each physical entity record comprising physical data values for at least one numeric attribute and partition-specifying values concerning values for one or more nominal attributes; [0039] a computing device comprising a processor, tangible non-volatile memory, program code present on said memory for instructing said processor; [0040] wherein the communication module is arranged to provide said computing device access to said database, [0041] wherein said computing device is configured for carrying out a method for calculating an anomaly score for each of said plurality of physical entity records, said method comprising the steps of: [0042] (a) retrieving said plurality of physical entity records via said communication module and optionally preparing said plurality of physical entity records for partitioning; [0043] (b) partitioning said plurality of physical entity records, by associating a partition with each distinct combination of partition-specifying values present in said plurality of physical entity records and grouping said physical entity records according to said partitions; [0044] (c) for each of said partitions obtained in step (b), training an unsupervised anomaly detection algorithm on the physical data values of the physical entity records belonging to said partition, obtaining a trained anomaly detection model for each of said partitions; [0045] (d) for each physical entity record belonging to said plurality of physical entity records, calculating the anomaly score by means of the trained anomaly detection model that is associated with the partition to which the physical entity record belongs; preferably, via the communication module, updating each physical entity record in the database by adding its associated anomaly score calculated in step (d) and/or preferably, via the communication module, storing each of said trained anomaly detection models for each of said partitions in said database. [0046] The advantage of such a system lies in the full consideration of nominal attributes, as indicated briefly above. As mentioned, in many applications, records in general consist of both nominal and numeric attributes. In fact, many data sets including insurance fraud detection data sets usually consist of both nominal and numeric attributes (Chandola, V., Banerjee, A., & Kumar, V. (2009). Anomaly Detection: A Survey. ACM Computing Surveys (CSUR), 41 (3), 15:1-15:58). As such, the present invention is particularly useful for applications such as insurance fraud detection where nominal attributes are available, using all available information in the anomaly detection.")
including an indication as to whether an anomaly has been detected within [the vehicle repair invoice] thereby flagging the insurance claim as including fraud.
(Matyska US20200334228 at paras. 36-46) ("[0036] In one embodiment of the invention, the system or the operational system handles records that concern insurance claims. In this context, it is assumed that an insurance company may require said system or said operational system for processing and analysis of data regarding insurance claims and payout of insurance claims. The system and operational system may be multi-layered, wherein data is received from claimants, health care providers, medical professionals, diagnostic persons, as well as, internal processing by members of the insurance company. The data present in the record of the insurance claim typically undergoes processing and analysis with established business rules of the insurance company. In this context, the “user” providing an insurance claim may in one embodiment be the claimant, but may as well be anyone involved in the processing of the claim. The “operator” on the other hand is typically someone from the insurance company, but may also concern a third party responsible for performing fraud detection on insurance claims. [0037] In a first aspect, the present invention provides a system for detecting anomalies, said system comprising [0038] a communication module having access to a database comprising a plurality of physical entity records, each physical entity record comprising physical data values for at least one numeric attribute and partition-specifying values concerning values for one or more nominal attributes; [0039] a computing device comprising a processor, tangible non-volatile memory, program code present on said memory for instructing said processor; [0040] wherein the communication module is arranged to provide said computing device access to said database, [0041] wherein said computing device is configured for carrying out a method for calculating an anomaly score for each of said plurality of physical entity records, said method comprising the steps of: [0042] (a) retrieving said plurality of physical entity records via said communication module and optionally preparing said plurality of physical entity records for partitioning; [0043] (b) partitioning said plurality of physical entity records, by associating a partition with each distinct combination of partition-specifying values present in said plurality of physical entity records and grouping said physical entity records according to said partitions; [0044] (c) for each of said partitions obtained in step (b), training an unsupervised anomaly detection algorithm on the physical data values of the physical entity records belonging to said partition, obtaining a trained anomaly detection model for each of said partitions; [0045] (d) for each physical entity record belonging to said plurality of physical entity records, calculating the anomaly score by means of the trained anomaly detection model that is associated with the partition to which the physical entity record belongs; preferably, via the communication module, updating each physical entity record in the database by adding its associated anomaly score calculated in step (d) and/or preferably, via the communication module, storing each of said trained anomaly detection models for each of said partitions in said database. [0046] The advantage of such a system lies in the full consideration of nominal attributes, as indicated briefly above. As mentioned, in many applications, records in general consist of both nominal and numeric attributes. In fact, many data sets including insurance fraud detection data sets usually consist of both nominal and numeric attributes (Chandola, V., Banerjee, A., & Kumar, V. (2009). Anomaly Detection: A Survey. ACM Computing Surveys (CSUR), 41 (3), 15:1-15:58). As such, the present invention is particularly useful for applications such as insurance fraud detection where nominal attributes are available, using all available information in the anomaly detection.")
Therefore, it would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Hutchins, Guo, Farmer, Tsai, Neelamana, and Matyska, because it allows for improved methods to efficiently and accurately read electronic documents included in a corpus of electronic documents, categorize the documents, and classify the data in accordance with, for example, the ontology of a domain. (Matyska at Abstract and paras. 27-29).
As per claim 9,
Hutchins does not explicitly teach, however, Guo does teach:
wherein the incident report includes an insurance claim submitted by a policyholder and associated with an accident, and
(Guo US20200211121 at paras. 61-66) ("[0061] For example, when the claim settlement materials including a payment invoice, an AI (Artificial Intelligence) technology may be used to identify the invoice information of the payment invoice, such as an invoice number, an invoice header, or a name of a payer. [0062] Based on the identified invoice information, the insurance platform can call an interface provided by a tax system to further authenticate the payment invoice. [0063] If the payment invoice is determined to be authentic, it can be determined that the payment invoice passes the authentication, and Step 210 may be performed. [0064] If the payment invoice is determined to be falsified, it can be determined that the payment invoice does not pass the authentication. The user is suspected of insurance fraud, and the credit platform can be notified to negatively update the credit information of the user. [0065] In another embodiment of the present specification, if the claim settlement materials include a proof of medical records, the AI technology may be used to identify whether the proof of medical records has a corresponding doctor's signature, or a hospital seal, etc. Identification can be made according to the requirements of proofs of real medical records. [0066] In an embodiment of the present specification, in addition to the AI technology, other technologies may also be used to authenticate the claim settlement materials, which are not limited by the present specification.")
wherein the document type is a medical care invoice, and
(Guo US20200211121 at paras. 19-21) ("[0019] The claim settlement request may be, but not limited to, a settlement request for a medical insurance claim, a settlement request for a mobile phone screen breakage insurance claim, a settlement request for a car insurance claim, or the like. [0020] In step 104, when the credit information of the user satisfies a credit constraint condition, the user is prompted to upload claim settlement materials. [0021] The claim settlement materials may be uploaded by the user who initiates the claim settlement request, and may include a photo of a payment invoice, a picture of an accident, or the like." "[0061] For example, when the claim settlement materials including a payment invoice, an AI (Artificial Intelligence) technology may be used to identify the invoice information of the payment invoice, such as an invoice number, an invoice header, or a name of a payer." "[0065] In another embodiment of the present specification, if the claim settlement materials include a proof of medical records, the AI technology may be used to identify whether the proof of medical records has a corresponding doctor's signature, or a hospital seal, etc. Identification can be made according to the requirements of proofs of real medical records.")
based upon the extracted content and stored historical medical care invoice data, and
(Guo US20200211121 at paras. 19-21) ("[0019] The claim settlement request may be, but not limited to, a settlement request for a medical insurance claim, a settlement request for a mobile phone screen breakage insurance claim, a settlement request for a car insurance claim, or the like. [0020] In step 104, when the credit information of the user satisfies a credit constraint condition, the user is prompted to upload claim settlement materials. [0021] The claim settlement materials may be uploaded by the user who initiates the claim settlement request, and may include a photo of a payment invoice, a picture of an accident, or the like." "[0061] For example, when the claim settlement materials including a payment invoice, an AI (Artificial Intelligence) technology may be used to identify the invoice information of the payment invoice, such as an invoice number, an invoice header, or a name of a payer." "[0065] In another embodiment of the present specification, if the claim settlement materials include a proof of medical records, the AI technology may be used to identify whether the proof of medical records has a corresponding doctor's signature, or a hospital seal, etc. Identification can be made according to the requirements of proofs of real medical records.")
the medical care invoice…
(Guo US20200211121 at paras. 19-21) ("[0019] The claim settlement request may be, but not limited to, a settlement request for a medical insurance claim, a settlement request for a mobile phone screen breakage insurance claim, a settlement request for a car insurance claim, or the like. [0020] In step 104, when the credit information of the user satisfies a credit constraint condition, the user is prompted to upload claim settlement materials. [0021] The claim settlement materials may be uploaded by the user who initiates the claim settlement request, and may include a photo of a payment invoice, a picture of an accident, or the like." "[0061] For example, when the claim settlement materials including a payment invoice, an AI (Artificial Intelligence) technology may be used to identify the invoice information of the payment invoice, such as an invoice number, an invoice header, or a name of a payer." "[0065] In another embodiment of the present specification, if the claim settlement materials include a proof of medical records, the AI technology may be used to identify whether the proof of medical records has a corresponding doctor's signature, or a hospital seal, etc. Identification can be made according to the requirements of proofs of real medical records.")
Therefore, it would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Hutchins and Guo, because it allows for an improved method for credit-based claim settlement. Also, claim settlement efficiency can be greatly enhanced, and claim settlement experience of the user can be improved. Claim settlement and smart online verification of the claim settlement materials can also protect interests of insurance companies and avoid financial losses caused by insurance fraud and other acts effectively. (Guo at Abstract and paras. 2-8).
Hutchins, Guo, Farmer, and Tsai do not explicitly teach, however, Neelamana does teach:
(ii) causing a graphical user interface to be displayed on an administrator computing device
(Neelamana US20200143257 at paras. 50-51) ("[0050] The GUI generator 408 can include a user interface that generates a display for the administrator to interact with the system (e.g., as discussed in the context of at least FIG. 12-15). The API server 409 can be an interface between the GUI generator 408 and the display 410. The display 410 can show the user interface generated by the GUI generator 408 to the administrator (e.g., as discussed in the context of at least FIG. 12-15)." )
Therefore, it would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Hutchins, Guo, Farmer, Tsai, and Neelamana, because it allows for improved methods to efficiently and accurately read electronic documents included in a corpus of electronic documents, categorize the documents, and classify the data in accordance with, for example, the ontology of a domain. (Neelamana at Abstract and paras. 27-29).
Hutchins, Guo, Farmer, Tsai, and Neelamana do not explicitly teach, however, Matyska does teach:
wherein executing the content verification module to verify the extracted content further comprises (i) performing anomaly detection
(Matyska US20200334228 at paras. 36-46) ("[0036] In one embodiment of the invention, the system or the operational system handles records that concern insurance claims. In this context, it is assumed that an insurance company may require said system or said operational system for processing and analysis of data regarding insurance claims and payout of insurance claims. The system and operational system may be multi-layered, wherein data is received from claimants, health care providers, medical professionals, diagnostic persons, as well as, internal processing by members of the insurance company. The data present in the record of the insurance claim typically undergoes processing and analysis with established business rules of the insurance company. In this context, the “user” providing an insurance claim may in one embodiment be the claimant, but may as well be anyone involved in the processing of the claim. The “operator” on the other hand is typically someone from the insurance company, but may also concern a third party responsible for performing fraud detection on insurance claims. [0037] In a first aspect, the present invention provides a system for detecting anomalies, said system comprising [0038] a communication module having access to a database comprising a plurality of physical entity records, each physical entity record comprising physical data values for at least one numeric attribute and partition-specifying values concerning values for one or more nominal attributes; [0039] a computing device comprising a processor, tangible non-volatile memory, program code present on said memory for instructing said processor; [0040] wherein the communication module is arranged to provide said computing device access to said database, [0041] wherein said computing device is configured for carrying out a method for calculating an anomaly score for each of said plurality of physical entity records, said method comprising the steps of: [0042] (a) retrieving said plurality of physical entity records via said communication module and optionally preparing said plurality of physical entity records for partitioning; [0043] (b) partitioning said plurality of physical entity records, by associating a partition with each distinct combination of partition-specifying values present in said plurality of physical entity records and grouping said physical entity records according to said partitions; [0044] (c) for each of said partitions obtained in step (b), training an unsupervised anomaly detection algorithm on the physical data values of the physical entity records belonging to said partition, obtaining a trained anomaly detection model for each of said partitions; [0045] (d) for each physical entity record belonging to said plurality of physical entity records, calculating the anomaly score by means of the trained anomaly detection model that is associated with the partition to which the physical entity record belongs; preferably, via the communication module, updating each physical entity record in the database by adding its associated anomaly score calculated in step (d) and/or preferably, via the communication module, storing each of said trained anomaly detection models for each of said partitions in said database. [0046] The advantage of such a system lies in the full consideration of nominal attributes, as indicated briefly above. As mentioned, in many applications, records in general consist of both nominal and numeric attributes. In fact, many data sets including insurance fraud detection data sets usually consist of both nominal and numeric attributes (Chandola, V., Banerjee, A., & Kumar, V. (2009). Anomaly Detection: A Survey. ACM Computing Surveys (CSUR), 41 (3), 15:1-15:58). As such, the present invention is particularly useful for applications such as insurance fraud detection where nominal attributes are available, using all available information in the anomaly detection.")
including an indication as to whether an anomaly has been detected within [the medical care invoice] thereby flagging the insurance claim as including fraud.
(Matyska US20200334228 at paras. 36-46) ("[0036] In one embodiment of the invention, the system or the operational system handles records that concern insurance claims. In this context, it is assumed that an insurance company may require said system or said operational system for processing and analysis of data regarding insurance claims and payout of insurance claims. The system and operational system may be multi-layered, wherein data is received from claimants, health care providers, medical professionals, diagnostic persons, as well as, internal processing by members of the insurance company. The data present in the record of the insurance claim typically undergoes processing and analysis with established business rules of the insurance company. In this context, the “user” providing an insurance claim may in one embodiment be the claimant, but may as well be anyone involved in the processing of the claim. The “operator” on the other hand is typically someone from the insurance company, but may also concern a third party responsible for performing fraud detection on insurance claims. [0037] In a first aspect, the present invention provides a system for detecting anomalies, said system comprising [0038] a communication module having access to a database comprising a plurality of physical entity records, each physical entity record comprising physical data values for at least one numeric attribute and partition-specifying values concerning values for one or more nominal attributes; [0039] a computing device comprising a processor, tangible non-volatile memory, program code present on said memory for instructing said processor; [0040] wherein the communication module is arranged to provide said computing device access to said database, [0041] wherein said computing device is configured for carrying out a method for calculating an anomaly score for each of said plurality of physical entity records, said method comprising the steps of: [0042] (a) retrieving said plurality of physical entity records via said communication module and optionally preparing said plurality of physical entity records for partitioning; [0043] (b) partitioning said plurality of physical entity records, by associating a partition with each distinct combination of partition-specifying values present in said plurality of physical entity records and grouping said physical entity records according to said partitions; [0044] (c) for each of said partitions obtained in step (b), training an unsupervised anomaly detection algorithm on the physical data values of the physical entity records belonging to said partition, obtaining a trained anomaly detection model for each of said partitions; [0045] (d) for each physical entity record belonging to said plurality of physical entity records, calculating the anomaly score by means of the trained anomaly detection model that is associated with the partition to which the physical entity record belongs; preferably, via the communication module, updating each physical entity record in the database by adding its associated anomaly score calculated in step (d) and/or preferably, via the communication module, storing each of said trained anomaly detection models for each of said partitions in said database. [0046] The advantage of such a system lies in the full consideration of nominal attributes, as indicated briefly above. As mentioned, in many applications, records in general consist of both nominal and numeric attributes. In fact, many data sets including insurance fraud detection data sets usually consist of both nominal and numeric attributes (Chandola, V., Banerjee, A., & Kumar, V. (2009). Anomaly Detection: A Survey. ACM Computing Surveys (CSUR), 41 (3), 15:1-15:58). As such, the present invention is particularly useful for applications such as insurance fraud detection where nominal attributes are available, using all available information in the anomaly detection.")
Therefore, it would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Hutchins, Guo, Farmer, Tsai, Neelamana, and Matyska, because it allows for improved methods to efficiently and accurately read electronic documents included in a corpus of electronic documents, categorize the documents, and classify the data in accordance with, for example, the ontology of a domain. (Matyska at Abstract and paras. 27-29).
Claims 10, 17, and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Hutchins, U.S. Patent Application Publication Number 2020/0210490; in view of Guo, U.S. Patent Application Publication Number 2020/0211121; in view of Farmer, U.S. Patent Application Publication Number 2021/0004909; in view of Tsai, U.S. Patent Application Publication Number 2020/0192862; in view of Perram, U.S. Patent Application Publication Number 2018/0075138.
As per claim 10,
Hutchins, Guo, Farmer, and Tsai do not explicitly teach, however, Perram does teach:
wherein executing the classification module to classify the document as one document type of a plurality of document types comprises: generating a confidence score for the document for each of the plurality of document types; ordering the confidence scores; and classifying the document as the one document types based upon the highest confidence score.
(Perram US20180075138 at paras. 119-121) ("[0119] In one embodiment, dynamic text shot analysis provides QA of the document classification. A user confirms the document classification by text shot analysis by viewing document text to compare to the clustering result and either confirms the classification as correct by going to the next document or by making a classification correction. Corrections can be made, for example, by assigning the document to another doc type category or classification. Database updates will occur and a check performed to ensure that all corrective actions were in fact updated. Some of the text shots may be indecipherable due to poor text quality from OCR, however those documents can be filtered using a minimum word filter (excluding stop words) and tagging failing documents for linear review. In that case, the user may need to view the native file in order to determine what document type category is relevant to assist with the document classification. In addition to employing a minimum word filter to isolate documents with poor OCR, a Minimum Word Filter/Word Count filter can be used to examine the first number of words in a document as required to perform the classification. This is applicable, for example, with compound documents such as large page count documents (typically PDF) or collections of multiple document types pertaining to a project, equipment envelope, or other factor. For example, the first 1000 words in one of these large documents can serve as a proxy for the type of compound document being processed. [0120] One process of classification quality assurance 400 can use a clustering method to analyse each document set by classification confidence as shown in FIG. 4. Once classification 402 is initiated, the QA function is accessed 404 and the groups of documents are displayed by classification confidence 406 as a confidence ranking. In one example, the utility can provide an equivalent to a green/yellow/red confidence level for results at the field level, and allow each category to be reviewed independently and by field. One of the document groups is then selected for QA 408 and the utility provides a classification accuracy 410 and confidence level 412. The system then returns a number and list of documents for review 414. A user reviews each document or a selection of documents from the list by viewing either text or the native file 416. Document QA 418 is then evaluated. If the correct classification is determined to have been applied, the user advances to the next document 426. If the classification is incorrect, the user manually applies a document classification 420 and the database is updated to register the correction 422. Once the classification of the selected document group is complete, a review log is provided of QA activity and a report produced 424.")
Therefore, it would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Hutchins, Guo, Farmer, Tsai, and Perram, because it allows for improved methods for electronic document management that can be applied to large groups of documents to create an organized classification structure. (Perram at Abstract and paras. 1-13).
Claims 17 and 20 are substantially similar to claim 10, thus, they are rejected on similar grounds.
Claim 16 is rejected under 35 U.S.C. 103 as being unpatentable over Hutchins, U.S. Patent Application Publication Number 2020/0210490; in view of Guo, U.S. Patent Application Publication Number 2020/0211121; in view of Farmer, U.S. Patent Application Publication Number 2021/0004909; in view of Tsai, U.S. Patent Application Publication Number 2020/0192862; in view of Matyska, U.S. Patent Application Publication Number 2020/0334228.
As per claim 16,
Hutchins does not explicitly teach, however, Guo does teach:
wherein the document type is one of vehicle repair invoice and medical care invoice, and
(Guo US20200211121 at paras. 19-21) ("[0019] The claim settlement request may be, but not limited to, a settlement request for a medical insurance claim, a settlement request for a mobile phone screen breakage insurance claim, a settlement request for a car insurance claim, or the like. [0020] In step 104, when the credit information of the user satisfies a credit constraint condition, the user is prompted to upload claim settlement materials. [0021] The claim settlement materials may be uploaded by the user who initiates the claim settlement request, and may include a photo of a payment invoice, a picture of an accident, or the like." "[0061] For example, when the claim settlement materials including a payment invoice, an AI (Artificial Intelligence) technology may be used to identify the invoice information of the payment invoice, such as an invoice number, an invoice header, or a name of a payer." "[0065] In another embodiment of the present specification, if the claim settlement materials include a proof of medical records, the AI technology may be used to identify whether the proof of medical records has a corresponding doctor's signature, or a hospital seal, etc. Identification can be made according to the requirements of proofs of real medical records.")
based upon the extracted document content and a corresponding one of stored historical vehicle repair invoice data and stored historical medical care invoice data.
(Guo US20200211121 at paras. 19-21) ("[0019] The claim settlement request may be, but not limited to, a settlement request for a medical insurance claim, a settlement request for a mobile phone screen breakage insurance claim, a settlement request for a car insurance claim, or the like. [0020] In step 104, when the credit information of the user satisfies a credit constraint condition, the user is prompted to upload claim settlement materials. [0021] The claim settlement materials may be uploaded by the user who initiates the claim settlement request, and may include a photo of a payment invoice, a picture of an accident, or the like." "[0061] For example, when the claim settlement materials including a payment invoice, an AI (Artificial Intelligence) technology may be used to identify the invoice information of the payment invoice, such as an invoice number, an invoice header, or a name of a payer." "[0065] In another embodiment of the present specification, if the claim settlement materials include a proof of medical records, the AI technology may be used to identify whether the proof of medical records has a corresponding doctor's signature, or a hospital seal, etc. Identification can be made according to the requirements of proofs of real medical records.")
Therefore, it would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Hutchins and Guo, because it allows for an improved method for credit-based claim settlement. Also, claim settlement efficiency can be greatly enhanced, and claim settlement experience of the user can be improved. Claim settlement and smart online verification of the claim settlement materials can also protect interests of insurance companies and avoid financial losses caused by insurance fraud and other acts effectively. (Guo at Abstract and paras. 2-8).
Hutchins, Guo, Farmer, and Tsai do not explicitly teach, however, Matyska does teach:
wherein executing the content verification module to verify the extracted document content comprises performing anomaly detection
(Matyska US20200334228 at paras. 36-46) ("[0036] In one embodiment of the invention, the system or the operational system handles records that concern insurance claims. In this context, it is assumed that an insurance company may require said system or said operational system for processing and analysis of data regarding insurance claims and payout of insurance claims. The system and operational system may be multi-layered, wherein data is received from claimants, health care providers, medical professionals, diagnostic persons, as well as, internal processing by members of the insurance company. The data present in the record of the insurance claim typically undergoes processing and analysis with established business rules of the insurance company. In this context, the “user” providing an insurance claim may in one embodiment be the claimant, but may as well be anyone involved in the processing of the claim. The “operator” on the other hand is typically someone from the insurance company, but may also concern a third party responsible for performing fraud detection on insurance claims. [0037] In a first aspect, the present invention provides a system for detecting anomalies, said system comprising [0038] a communication module having access to a database comprising a plurality of physical entity records, each physical entity record comprising physical data values for at least one numeric attribute and partition-specifying values concerning values for one or more nominal attributes; [0039] a computing device comprising a processor, tangible non-volatile memory, program code present on said memory for instructing said processor; [0040] wherein the communication module is arranged to provide said computing device access to said database, [0041] wherein said computing device is configured for carrying out a method for calculating an anomaly score for each of said plurality of physical entity records, said method comprising the steps of: [0042] (a) retrieving said plurality of physical entity records via said communication module and optionally preparing said plurality of physical entity records for partitioning; [0043] (b) partitioning said plurality of physical entity records, by associating a partition with each distinct combination of partition-specifying values present in said plurality of physical entity records and grouping said physical entity records according to said partitions; [0044] (c) for each of said partitions obtained in step (b), training an unsupervised anomaly detection algorithm on the physical data values of the physical entity records belonging to said partition, obtaining a trained anomaly detection model for each of said partitions; [0045] (d) for each physical entity record belonging to said plurality of physical entity records, calculating the anomaly score by means of the trained anomaly detection model that is associated with the partition to which the physical entity record belongs; preferably, via the communication module, updating each physical entity record in the database by adding its associated anomaly score calculated in step (d) and/or preferably, via the communication module, storing each of said trained anomaly detection models for each of said partitions in said database. [0046] The advantage of such a system lies in the full consideration of nominal attributes, as indicated briefly above. As mentioned, in many applications, records in general consist of both nominal and numeric attributes. In fact, many data sets including insurance fraud detection data sets usually consist of both nominal and numeric attributes (Chandola, V., Banerjee, A., & Kumar, V. (2009). Anomaly Detection: A Survey. ACM Computing Surveys (CSUR), 41 (3), 15:1-15:58). As such, the present invention is particularly useful for applications such as insurance fraud detection where nominal attributes are available, using all available information in the anomaly detection.")
Therefore, it would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Hutchins, Guo, Farmer, Tsai, and Matyska, because it allows for improved methods to efficiently and accurately read electronic documents included in a corpus of electronic documents, categorize the documents, and classify the data in accordance with, for example, the ontology of a domain. (Matyska at Abstract and paras. 27-29).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure and is available for review on Form PTO-892 Notice of References Cited.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MERRITT J HASBROUCK whose telephone number is (571)272-3109. The examiner can normally be reached M-F 9:00-5:00.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Christine Tran can be reached on 571-272-8103. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/MERRITT J HASBROUCK/Examiner, Art Unit 3695
/CHRISTINE M Tran/Supervisory Patent Examiner, Art Unit 3695
Prosecution Insights