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 .
Status of Claims
This action is responsive to claims and remarks filed 10/13/2025. Claims 1–2, 5, 9, 13, 16–18, and 20 have been amended. No claims have been cancelled, and there are no new claims.
Claims 1–20 are pending for examination.
Response to Arguments
In reference to 35 USC § 101
Applicant’s arguments, filed on 10/13/2025, with respect to the § 101 rejections have been fully considered and are persuasive.
Examiner notes that while the claims recite several limitations that are abstract ideas (mental processes), the claims as a whole are not directed to an abstract idea. See Ex Parte Desjardins, Appeal No. 2024-000567. Applicant amended the claims, which collectively now recite a detailed of training an anomaly-detecting machine learning model with metadata instead of raw documents, in an effort to enable computing resource usage and network communication to be more efficient. Examiner notes that the additional elements integrate the abstract idea into a practical application because the entire claim amounts to a detailed method that requires implementing a specific combination of hardware with the claimed algorithm (as opposed to a broad recitation at a high level of generality), and the specific combination of hardware and instructions recited in the additional element amounts to an improvement to the functioning of a computer/field, as set forth by MPEP 2106.05(a)), which states “the claim must include the components or steps of the invention that provide the improvement described in the specification.” Pursuant to this requirement set forth by the MPEP, examiner points out that the Specification states in at least [0026]: “instead of processing the content of a vast volume of documents associated with a large population of users, detecting anomalies based on metadata and machine learned model implementations herein may, inter alia, achieve improved computing resource usage efficiency as well as network communication efficiency, thereby leading to more comprehensive monitoring and more accurate, timely, and/or customized detection of anomalies.” Therefore, the additional elements reflect the improvement set forth and explains what the resulting improvement is.
Thus, the additional limitations do amount to significantly more, and the § 101 rejections are withdrawn.
In reference to 35 USC § 103
Applicant’s arguments, filed on 10/13/2025, with respect to the amended claims have been fully considered but are not persuasive.
Applicant argues, beginning on Pg. 18 of the Remarks, that “the claim requires different classifier models to extract metadata from different categories of documents. All the cited references are silent on such claim element.” Examiner respectfully disagrees. Examiner contends that Gwozdz indeed teaches using different models to in the processing pipeline in at least paragraph [0056]: “The IDE manager 273 allows users to modify, delete and add expressions to the System. The model manager 274 allows users to select machine learned models for execution in a pipeline.” See § 103 rejections below for detailed analysis.
Applicant argues, beginning on Pg. 19 of the Remarks, that “Gwozdz does not teach and/or suggest how to extract the metadata, and certainly not in the above unique manner recited in claim 1.” Examiner respectfully disagrees. Examiner contends that Gwozdz indeed teaches extracting metadata in at least paragraphs [0046, 0048, 0051–0052]: “(b) extract information and capture the information into structured files,” and “The document conversion system provides a utility for extracting document data and metadata.” See § 103 rejections below for detailed analysis.
Applicant argues, beginning on Pg. 19 of the Remarks, that “Applicant notes that the claim recited machine learning model is trained from metadata instead of raw documents. Applicant respectfully submits that none of the cited references.” Examiner respectfully disagrees. Examiner contends that Gwozdz indeed teaches training from metadata in at least paragraphs [0055–0056]: “The ML conversion component converts the underlying Lume representations into machine-readable vectors for fast analytic processing. The classification component maps a given set of input into a learned set of outputs (categorical or numeric) based on initial training and configuration.” Examiner notes the Lume representations are based on extracted metadata. See Gwozdz paragraphs [0051–0052]. See § 103 rejections below for detailed analysis.
Applicant argues, beginning on Pg. 20 of the Remarks, that “Applicant notes that the ‘digital token’ is dynamically generated to verify the detected anomalies as recited in claim 1. Although Gwozdz discloses the concept of token, Gwozdz does not disclose using the token in the manner recited in the claim.” Examiner respectfully disagrees. Examiner contends that Gwozdz indeed teaches dynamically generating tokens to verify anomalies in at least paragraphs [0046, 0160]: “(c) assess the information in the context of policies, rules, regulations, and/or business objectives, and (d) answer questions, produce insights, and identify patterns and anomalies in the information,” and “Step 2026 identifies partition elements. Step 2028 applies tokenization.” Examiner notes the BRI of anomalies is something different or deviating from the norm. See § 103 rejections below for detailed analysis.
Therefore, examiner maintains the § 103 rejections.
Claim Rejections - 35 USC § 103
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.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 1–3, 5–9, 11–12, and 16–20 are rejected under 35 U.S.C. 103 as being unpatentable over Gwozdz et al., (US-20220019624-A1), hereinafter “Gwozdz”, in view of Yelheri et al., (US 20220138152 A1), hereinafter “Yelheri” and further in view of Goodman et al., (US 5983170 A), hereinafter “Goodman”.
Regarding claim 1, Gwozdz teaches:
receiving, by one or more processors of a platform from a plurality of data sources using at least one application programming interface (API), a plurality of electronic documents (Gwozdz Fig. 19, ¶0157: “Data Source 1916 and Data Source 1918 may communicate documents to Raw Document Services 1921. Raw Document Services 1921 may include interfaces or APIs to access with various data sources, such as Index API 1922 and Perfect Info API 1924. Processing information may be communicated to Pipeline 1930. In addition, documents may be communicated to File Store 1926, such as NFS (Network File System) file store. Documents from File Store 1926 may be loaded into a viewer through Server 1934”);
organizing, by the one or more processors based on a predetermined rule, the plurality of electronic documents into at least a first and second category of electronic documents (Gwozdz Fig. 2, ¶0055: “The classification component maps a given set of input into a learned set of outputs (categorical or numeric) based on initial training and configuration. The clustering component produces groups of vectors based on a pre-determined similarity metric”);
extracting, by the one or more processors, a plurality of sets of metadata items from the plurality of electronic documents with each set of the plurality of sets of the metadata items corresponding to each of the plurality of electronic documents (Gwozdz Figs. 10, 15, 16, ¶0046: “The System can be deployed to ingest, understand and analyze the documents, communications, and websites that make up the rapidly growing body of structured data and unstructured data. According to one embodiment, the System may be designed to: (a) read transcripts, tax filings, communications, financial reports, and similar documents and input files, (b) extract information and capture the information into structured files, (c) assess the information in the context of policies, rules, regulations, and/or business objectives, and (d) answer questions, produce insights, and identify patterns and anomalies in the information. The System can capture and store subject matter expertise; ingest, mine and classify documents using natural language processing (NLP); incorporate advanced machine learning and artificial intelligence methods; and utilize collaborative, iterative refinement with advisory and client stakeholders”; see also Gwozdz Fig. 1, ¶0048: “In addition, the appropriate ingestion approach will be used to convert and preserve document metadata and formatting information. In many instances, the input unstructured data will reside in a multitude of documents which together form a corpus 15 of documents that is stored in a dataset”; see also Gwozdz Fig. 2, ¶0051–0052: “The document conversion system provides a utility for extracting document data and metadata”—[(emphasis added) wherein the corpus of specific use case user documents are analyzed to extract information stored in structured files (i.e., metadata) associated with the user documents),
the extracting using a first classifier model for the first category of electronic documents, the extracting using a second classifier model for the second category of electronic documents (Gwozdz Fig. 2, ¶0056: “The IDE manager 273 allows users to modify, delete and add expressions to the System. The model manager 274 allows users to select machine learned models for execution in a pipeline”—[wherein the model manager allows users to use a second classifier model for execution in a pipeline]),
determining, by the one or more processors, a plurality of sets of features based on the plurality of sets of metadata items (Gwozdz ¶0082: “In addition, training an accurate machine learning model generally requires a large number of labeled documents. Using the IDE to integrate the domain knowledge with machine learning can reduce the number of documents needed to train an accurate model by an order of magnitude, by utilizing expert-derived features. This is because the machine learning problems involving unstructured data are generally overdetermined, and the ability to select accurate, and interpretable features requires more data than is generally available. For example, in documents, many tens of thousands of features can exist, including the dictionary of words, orthographic features, document structures, syntactic features, and semantic features. Furthermore, according to an exemplary embodiment of the invention, individuals such as subject matter experts (SMEs) who input expressions do not need computer coding skills, as expressions can be created using a domain specific language that can be codified in no-code environments, such as in spreadsheets (CSV or XLSX) or through an IDE user interface. Thereby the SME can create domain relevant features that can be leveraged for the machine training process. The IDE UI allows users to modify, delete and add expressions to the System and visualize elements created by executing the IDE. In addition, expressions can be designed to be interchangeable. They can be created for reuse in use cases throughout an industry or problem set. Additionally, the IDE can be designed to leverage the Lume format for storing and working with documents. This design allows the annotations and metadata to be inputs for the expressions, in addition to the textual features that exist in the document”—[(emphasis added)]);
transforming, by the one or more processors, the plurality of sets of features into a set of feature vectors, each feature vector tagged to indicate a correspondence to a particular anomaly or not (Gwozdz ¶0046: “The System can be deployed to ingest, understand and analyze the documents, communications, and websites that make up the rapidly growing body of structured data and unstructured data. According to one embodiment, the System may be designed to: (a) read transcripts, tax filings, communications, financial reports, and similar documents and input files, (b) extract information and capture the information into structured files, (c) assess the information in the context of policies, rules, regulations, and/or business objectives, and (d) answer questions, produce insights, and identify patterns and anomalies in the information.”; see also Gwozdz Fig. 2, ¶0055: “The ML conversion component converts the underlying Lume representations into machine-readable vectors for fast analytic processing. The classification component maps a given set of input into a learned set of outputs (categorical or numeric) based on initial training and configuration. The clustering component produces groups of vectors based on a pre-determined similarity metric. The deep learning component is a specific type of machine learning component 253 that utilizes a many-layer network representation of nodes and connections to learn outputs (categorical or numeric)”; see also Gwozdz Fig. 6, ¶0074: “As the Lumes in the dataset are converted to Lume format in step 602, the results are stored in the dataset. The conversion includes the creation of the Lume data structure (i.e., loop 602b), the conversion of the format-specific metadata into Lume Elements (i.e., step 602a), and additional annotations that are needed, such as semantic annotation, natural language processing, creating domain-specific features, or a vectorization to a quantitative fingerprint. More specifically, in step 601, the dataset documents are identified in the URI, and then the Lumes containing the file data is passed to 602”—[(emphasis added) wherein the system converts (i.e., transforms) the metadata information into Lumes (i.e., vectors) which are vectorizations to a quantitative fingerprint (i.e., correspondence to a particular anomaly)]);
training, by the one or more processors, based on the plurality of sets of features vectors as sole training data, a data anomaly-detection machine learning model to obtain a trained data anomaly-detection machine learning model, the data anomaly-detection machine learning model comprising a set of triggering rules that are configured to determine a plurality of anomalies within a particular set of metadata items (Gwozdz ¶0046: “According to one embodiment, the System may be designed to: (a) read transcripts, tax filings, communications, financial reports, and similar documents and input files, (b) extract information and capture the information into structured files, (c) assess the information in the context of policies, rules, regulations, and/or business objectives, and (d) answer questions, produce insights, and identify patterns and anomalies in the information. The System can capture and store subject matter expertise; ingest, mine and classify documents using natural language processing (NLP); incorporate advanced machine learning and artificial intelligence methods; and utilize collaborative, iterative refinement with advisory and client stakeholders”; see also Gwozdz Fig. 2, ¶¶0055–0056: “FIG. 2 also illustrates that a number of machine learning (ML) components 253 can be incorporated into the System. For example, the System may include an ML conversion component, a classification component, a clustering component, and a deep learning component. The ML conversion component converts the underlying Lume representations into machine-readable vectors for fast analytic processing. The classification component maps a given set of input into a learned set of outputs (categorical or numeric) based on initial training and configuration. The clustering component produces groups of vectors based on a pre-determined similarity metric. The model manager 274 allows users to select machine learned models for execution in a pipeline. A search interface 272 (i.e., data exploration) allows users to find data loaded in the platform. The document & corpus annotator 271 (i.e., annotation manager) and editors allows users to manually create and modify annotations on a Lume and group Lumes into corpora for training and testing the System. Visual workflow interfaces 275 (i.e., workbench) provide a visual capability for building workflows, and can be used to create histograms and other statistical views of the data stored in the platform”—[(emphasis added) wherein the system uses rules to identify patterns and anomalies in the information by training the machine learning model with the Lumes which are created based on the metadata]);
utilizing, by the one or more processors, the trained data anomaly-detection machine learning model to analyze a particular set of metadata items of a particular electronic document associated with an account of a user to detect one or more anomalies in the particular set of metadata items based on the set of triggering rules (Gwozdz Fig. 1, ¶¶0049–0050: “Manual review of the contracts to assess compliance with new regulations is one alternative, but that approach could well involve a very substantial time commitment and extensive costs for experts to review the contracts. Alternatively, the System can be configured to read the contracts, extract information and capture the information into structured files, assess the information in the context of the amended regulations and/or business objectives, and answer questions, produce insights, and identify patterns and anomalies in the contracts. Referring to FIG. 1, the regulatory rule set is used by subject matter experts in the manual review and are also translated into related semantics 21 and a determination strategy 22 in the machine review. Semantics 21 include domain knowledge embodied in an ontology or knowledge base consisting of entities, relationships and facts. The determination strategy 22 consists of business rules applied to the related semantics 21 to answer specific questions. This includes document-level assessments (such as compliant vs non-compliant), feature-level extraction (termination dates, key entities), inferred facts (such as utilizing extracted facts and the ontology to make inferences), or to identify risk (such as identify portions of the document that require further scrutiny). The machine learning review 25a analyzes dispositive features 26a, such as the specified contract terms, dates, entities, and facts, and undertakes an automated document analysis assessment 27a through the use of an intelligent domain engine (sometimes referred to herein as the “IDE”). The machine learning review 25a assists the machine compliance determination 28a by providing confidence scoring. In parallel, the manual review 25b of selected documents, conducted for example by a subject matter expert, analyzes dispositive features 26b and undertakes a document analysis assessment 27b and a manual compliance determination 28b for a sample of the contracts”—[(emphasis added)]); and
dynamically generating, by the one or more processors, a digital token to verify the one or more detected anomalies in the particular set of metadata items (Gwozdz ¶0046, ¶0052–0053: “(c) assess the information in the context of policies, rules, regulations, and/or business objectives, and (d) answer questions, produce insights, and identify patterns and anomalies in the information” and “In one application, a workflow of processing can be chained together to identify sentences, tokens, and other document structure; entity identification; annotation against a taxonomy or ontology; and the intelligent domain engine 251 can utilize this information to create derived and inferred features … As an example, the NLP component 255 processes a Lume 240 and adds additional Lume Elements to indicate human language specific constructs in the underlying data, including word tokens, part-of-speech, semantic role labels, named entities, co-referent phrases, etc.”; see also Gwozdz ¶0160: “Step 2026 identifies partition elements. Step 2028 applies tokenization. Step 2030 applies custom text extraction. Based on the extraction, postgres integration may be applied at 2032. JSON output may be communicated via UI at 2034”—[(emphasis added) wherein the BRI of anomalies is something different or deviating from the norm]).
Gwozdz does not appear to explicitly teach:
automatically triggering, by the one or more processors and in response to the one or more anomalies, one or more actions associated with the account of the user; and
retraining, by the one or more processors, the trained data anomaly-detection machine learning model based on the triggering of the one or more actions and the generating of the digital token.
However, Yelheri teaches:
automatically triggering, by the one or more processors and in response to the one or more anomalies, one or more actions associated with the account of the user (Yelheri Fig. 7, ¶0176: “In an embodiment of performing an integrity check, the integrity check may be performed to implement anomaly detection. In an example of anomaly detection, the integrity check may be performed to determine whether a number of files modified in a snapshot during a timeframe conforms to an expected average of modifications to files, which may be calculated based upon historic access patterns by an anomaly detection algorithm. In an example of anomaly detection, the integrity check may be performed to determine whether an unexpected file operation has been performed with respect to a snapshot, such as an unexpected delete operation. In an example of anomaly detection, the integrity check may be performed to determine whether unexpected file encryption has been performed with respect to one or more objects, which may be indicative of ransomware or other malicious activity. In this way, if an anomaly is detected and/or other integrity issue is detected, then an alert may be generated and/or automated recovery actions may be performed such as re-baselining and/or reinitializing a snapshot and/or mirroring relationship used to backup snapshots of a source volume as snapshots to the object store 716”—[(emphasis added)]).
The methods of Gwozdz, the teachings of Yelheri, and the instant application are analogous art because they pertain to detecting anomalies in data associated with metadata.
It would be obvious to a person of ordinary skill in the art before the effective filing date of the invention to modify the methods of Gwozdz with the teachings of Yelheri to provide automated response actions based on detecting anomalies in data. One would be motivated to do so to detect integrity issues, ransomware, or other malicious activities (Yelheri ¶0176: “In this way, if an anomaly is detected and/or other integrity issue is detected, then an alert may be generated and/or automated recovery actions may be performed such as re-baselining and/or reinitializing a snapshot and/or mirroring relationship used to backup snapshots of a source volume as snapshots to the object store 716”).
Gwozdz in view of Yelheri does not appear to explicitly teach:
retraining, by the one or more processors, the trained data anomaly-detection machine learning model based on the triggering of the one or more actions and the generating of the digital token.
However, Goodman teaches:
retraining, by the one or more processors, the trained data anomaly-detection machine learning model based on the triggering of the one or more actions and the generating of the digital token (Goodman Col. 6–7, lines 60–6: “The token classifier 22 generates for each token, a classification that will identify the one of a plurality of predetermined database attributes for the token in the database record for the Web page. As indicated above, the classification tree methodology provides an identification of a classification based on prior training using a training set comprising a number of properly classified tokens. If the token classifier 22 is unable to determine a proper classification for a particular token, an operator, either local to the server computer 12 or controlling the token classifier 22 from a client computer 11(n), may provide a proper classification for the token. Thereafter, the classification tree may be retrained by a classifier maintenance module 25 using the training set expanded by the properly classified token”—[(emphasis added)]),
The methods of Gwozdz in view of Yelheri, the teachings of Goodman, and the instant application are analogous art because they pertain to detecting anomalies in data with models.
It would be obvious to a person of ordinary skill in the art before the effective filing date of the invention to modify the methods of Gwozdz in view of Yelheri with the teachings of Goodman to provide for retraining of a learning model based on a detected anomaly, a token, and an action. One would be motivated to do so to provide classifiers in order to effectively respond to queries (Goodman Col. 7, lines 16–20: “Thereafter, the database system 23 can use the new database records provided loaded by the token classifier, along with other previously-provided database records, to respond to database queries provided by a local or remote operator as described above.”).
Regarding claim 2, Gwozdz in view of Yelheri and Goodman teaches all the limitations of claim 1.
Gwozdz teaches:
wherein electronic documents of the plurality sets of electronic documents comprise one or more of: textual data, imagery data, audio data, video data, virtual token data, hologram data, augmented reality data, virtual reality data, and Internet of Things (IoT) data (Gwozdz Fig. 2, ¶0051: “Referring to FIG. 2, the architecture of the System is depicted according to an exemplary embodiment of the invention. As mentioned previously, the System can support information extraction and data analysis on structured and unstructured data. The input data 210 may take the form of various files or information of different types and formats such as documents, text, video, audio, tables, and databases. As shown in FIG. 2, the data to be analyzed can be input to a core document management system 220”—[(emphasis added)]).
Regarding claim 3, Gwozdz in view of Yelheri and Goodman teaches all the limitations of claim 1.
Gwozdz teaches:
wherein the detecting one or more anomalies in the particular set of metadata items comprises: determining, by the one or more processors, whether a risk level associated with the one or more anomalies (Gwozdz ¶0050: “The determination strategy 22 consists of business rules applied to the related semantics 21 to answer specific questions. This includes document-level assessments (such as compliant vs non-compliant), feature-level extraction (termination dates, key entities), inferred facts (such as utilizing extracted facts and the ontology to make inferences), or to identify risk (such as identify portions of the document that require further scrutiny). The machine learning review 25a analyzes dispositive features 26a, such as the specified contract terms, dates, entities, and facts, and undertakes an automated document analysis assessment 27a through the use of an intelligent domain engine (sometimes referred to herein as the “IDE”). The machine learning review 25a assists the machine compliance determination 28a by providing confidence scoring. In parallel, the manual review 25b of selected documents, conducted for example by a subject matter expert, analyzes dispositive features 26b and undertakes a document analysis assessment 27b and a manual compliance determination 28b for a sample of the contracts”—[(emphasis added)];
Yelheri teaches:
exceeds a threshold value (Yelheri ¶0233: “In another example, the creation of the serverless threads may be triggered to perform an integrity check upon a first object based upon an event corresponding to a determination that a second object was identified as being corrupt. The first object may be identified for the integrity check based upon the first object having a probability of being corrupt above a threshold probability based upon the second object being corrupt (e.g., the first object may correspond to an incremental snapshot that may share snapshot data with the second object that is corrupt)”—[(emphasis added) wherein the system identifies risk and compares the identified associated confidence score based on anomaly detection against a threshold probability to see if the score is above the threshold]).
The same motivation that was utilized for combining Gwozdz with Yelheri, as set forth in claim 1, is equally applicable to claim 2.
Regarding claim 5, Gwozdz in view of Yelheri and Goodman teaches all the limitations of claim 1.
Gwozdz teaches:
wherein the utilizing the trained data anomaly-detection machine learning model to analyze the particular set of metadata items of the particular electronic document associated with the account of the user comprises: scanning, by the one or more processors, the particular set of metadata items to detect one or more changes in the particular set of metadata items (Gwozdz Fig. 1, ¶0048: “FIG. 1 is a functional block diagram of a system for automated analysis of structured and unstructured data according to an exemplary embodiment of the invention. As shown in FIG. 1, the System integrates a variety of data sources, domain knowledge, and human interaction, in addition to the algorithms that ingest and structure the content. The System includes a scanning component 10 to ingest a plurality of documents 5 such as contracts, loan documents, and/or text files, and to extract related data 6. During the ingestion process, the System may incorporate OCR technology to convert an image (e.g., PDF image) into searchable characters and may incorporate NLP pre-processing to convert the scanned images into raw documents 11 and essential content 12. In addition, the appropriate ingestion approach will be used to convert and preserve document metadata and formatting information. In many instances, the input unstructured data will reside in a multitude of documents which together form a corpus 15 of documents that is stored in a dataset”—[(emphasis added)]).
Regarding claim 6, Gwozdz in view of Yelheri and Goodman teaches all the limitations of claim 5.
Yelheri teaches:
wherein the detecting one or more anomalies in the particular set of metadata items further comprises: determining, by the one or more processors, the one or more anomalies in the account of the user based on the one or more changes in the particular set of metadata items (Yelheri ¶¶0195–0197: “In some embodiments, multiple modes of integrity checking may be implemented. A first mode of integrity checking may correspond to periodic full scans of objects, such as yearly scans. The first mode of integrity checking may be implemented because storage devices, storing the objects, may fail. The first mode of integrity checking may also be implemented because the objects may be migrated and/or redistributed such as for scaling purposes, and thus a full scan may be performed to ensure the integrity of the objects after migration. A second mode of integrity checking may correspond to incremental scans of objects. Instead of having to list and compare all of the data of the two snapshots in order to identify the difference between the snapshots, which could take hours, a difference operation may be performed to quickly identify the difference between the snapshots. The difference operation can quickly identify the difference between the snapshots because the difference operation can quickly traverse the tree structure of the incremental snapshot to identify nodes and branches that have changed and should be evaluated, and skip nodes and branches that have not changed. For example, if a top/root node of a branch indicates that nothing has changed, then the entire branch can be skipped by the difference operation. Also, if an object has an integrity issue, then merely that object and children of the object are scanned. In this way, the difference operation may be able to identify the difference between the snapshots within seconds as opposed to hours because a full traversal is not performed”—[(emphasis added)]).
The same motivation that was utilized for combining Gwozdz with Yelheri, as set forth in claim 1, is equally applicable to claim 6.
Regarding claim 7, Gwozdz in view of Yelheri and Goodman teaches all the limitations of claim 1.
Gwozdz teaches:
associating, by the one or more processors, the feature vectors with a set of metadata items of historical electronic documents (Gwozdz Fig. 1, ¶0050: “Referring to FIG. 1, the regulatory rule set is used by subject matter experts in the manual review and are also translated into related semantics 21 and a determination strategy 22 in the machine review. Semantics 21 include domain knowledge embodied in an ontology or knowledge base consisting of entities, relationships and facts. The determination strategy 22 consists of business rules applied to the related semantics 21 to answer specific questions. This includes document-level assessments (such as compliant vs non-compliant), feature-level extraction (termination dates, key entities), inferred facts (such as utilizing extracted facts and the ontology to make inferences), or to identify risk (such as identify portions of the document that require further scrutiny)”; see also Gwozdz Fig. 2, ¶0052: “According to a preferred embodiment of the invention, the input data 210 is transformed into a common data format 230, referred to in FIG. 2 as “Lume.” Lume may preferably be the common format for all components and data storage”; see also Gwozdz Fig. 2, ¶0055: “FIG. 2 also illustrates that a number of machine learning (ML) components 253 can be incorporated into the System. For example, the System may include an ML conversion component, a classification component, a clustering component, and a deep learning component. The ML conversion component converts the underlying Lume representations into machine-readable vectors for fast analytic processing. The classification component maps a given set of input into a learned set of outputs (categorical or numeric) based on initial training and configuration. The clustering component produces groups of vectors based on a pre-determined similarity metric. The deep learning component is a specific type of machine learning component 253 that utilizes a many-layer network representation of nodes and connections to learn outputs (categorical or numeric)”—[(emphasis added)]).
Regarding claim 8, Gwozdz in view of Yelheri and Goodman teaches all the limitations of claim 1.
Gwozdz teaches:
wherein the automatically triggering, by the one or more processors and in response to the one or more anomalies, one or more actions associated with the account of the user comprises: generating a security token, by the one or more processors, in response to the one or more anomalies (Gwozdz Fig. 21, ¶0161: “FIG. 21 is an exemplary flowchart for a security coverage check process, according to an embodiment of the present invention. For example, the security coverage check process may involve providing a list of securities identifiers; checking for data and documents and confirming an analyzable universe”—[(emphasis added)]); and
initiating, by the one or more processors, the automatic triggering of the one or more actions associated with the account of the user based on the security token (Gwozdz Fig. 21, ¶0162: “Client 2110 may provide an input represented by Security Masterfile 2112 or Security in-app 2114. Process may initiate at 2116 and determine whether the input is a valid identifier at 2118. This may involve checking for presence in a security master. If yes, the process may determine whether this is a duplicate identifier at 2120 and logged at 2146. If not, the process may identify corresponding documents at 2122. This may be represented by a document flag in database, such as Postgres. The process may then identify a source, at 2124, 2126, 2128 and retrieve documents at 2130, 2132, 2134, 2136 and process documents at 2138. If a source is not identified and documents are not deemed relevant, the coverage may be logged as “No Linked” at 2150. If documents are identified and deemed relevant, coverage may be logged as “Documents” at 2152. Log processing details may be captured at 2154 and metadata details at 2156”—[(emphasis added)]).
Regarding claim 9, Gwozdz in view of Yelheri and Goodman teaches all the limitations of claim 1.
Yelheri teaches:
wherein the automatically triggering, by the one or more processors and in response to the one or more anomalies, one or more actions associated with the account of the user comprises transferring of electronic documents of the plurality of electronic documents (Yelheri ¶0167: “Data connector components may be instantiated through containers on an as need basis, and thus can be instantiated when integrity checking, anomaly detection, and/or file system metadata analysis is to be performed (e.g., instantiated on-demand in response to a determination that integrity checking, anomaly detection, and/or file system metadata analysis is to be performed). The data connector components may be deconstructed once the integrity checking, anomaly detection, and/or file system metadata analysis is finished, which can reduce the cost and/or compute of hosting the data connector components. Any number of data connector components may be instantiated so that multiple data connector components may performed integrity checking, anomaly detection, and/or file system metadata analysis in parallel upon objects, backup data, and/or snapshots in parallel. For example, a first data connector component 706 may be instantiated as a first container 704, a second data connector component 710 may be instantiated as a second container 708, and an nth data connector component 714 may be instantiated as an nth container 712. A data connector component and a container may be stateless, and thus containers may be onlined, offlined, upgraded, and/or have work transferred there between in a stateless manner”—[(emphasis added)]).
The same motivation that was utilized for combining Gwozdz with Yelheri, as set forth in claim 1, is equally applicable to claim 9.
Regarding claim 11, Gwozdz in view of Yelheri and Goodman teaches all the limitations of claim 1.
Gwozdz teaches:
wherein the activities comprise: credit reporting events, merchant events, financial account events, legal events, municipal regulation events, motor vehicle regulation events, household usage and maintenance events, and healthcare events (Gwozdz ¶¶0046–0047: “The System can be deployed to ingest, understand and analyze the documents, communications, and websites that make up the rapidly growing body of structured data and unstructured data. According to one embodiment, the System may be designed to: (a) read transcripts, tax filings, communications, financial reports, and similar documents and input files, (b) extract information and capture the information into structured files, (c) assess the information in the context of policies, rules, regulations, and/or business objectives, and (d) answer questions, produce insights, and identify patterns and anomalies in the information. Examples of policies or rules that the System can analyze may include, for example, new regulations, accounting standards, profitability targets, identification of accretive vs. dilutive projects, assessment of credit risk, asset selection, rebalancing a portfolio, or settlement outcomes, to name a few. Examples of documents that the System can analyze may include, for example, legal contracts, loan documents, securities prospectus, company financial filings, derivatives confirms and masters, insurance policies, insurance claims notes, customer service transcripts, and email exchanges”—[(emphasis added)]).
Regarding claim 12, Gwozdz in view of Yelheri and Goodman teaches all the limitations of claim 11.
Gwozdz teaches:
wherein the financial account events comprises one or more new account events and one or existing account events, the one or more new account events comprising a new credit card event, a new personal loan event, a new loan application event, a new car purchase event, a new car loan event, a new mortgage event, a new insurance policy event, a new mobile phone account event, a new utility account event, a new co-signer on a loan event, and a new reverse mortgage event; and the one or more existing account event comprising: a credit card event, a payment event, a purchase event, an identity event, an authentication event, a balance event, and a ownership event (Gwozdz ¶0047: “Examples of questions that the System can answer may include, for example, which documents comply with a certain policy or regulation, which assets are most risky, which claims warrant intervention, which customers are most/least likely to undergo attrition, which clients will have growing/shrinking wallet and market share, and which documents are experiencing a change in trend or meaning. Examples of policies or rules that the System can analyze may include, for example, new regulations, accounting standards, profitability targets, identification of accretive vs. dilutive projects, assessment of credit risk, asset selection, rebalancing a portfolio, or settlement outcomes, to name a few. Examples of documents that the System can analyze may include, for example, legal contracts, loan documents, securities prospectus, company financial filings, derivatives confirms and masters, insurance policies, insurance claims notes, customer service transcripts, and email exchanges”; see also Gwozdz ¶0168: “FIG. 23 is an exemplary data flow of a Securities Analyzer, according to an embodiment of the present invention. An embodiment of the present invention is directed to a Securities Analyzer for Asset-Backed Securities. An Asset-Backed Security (ABS) represents a type of financial investment that is collateralized by an underlying pool of assets—usually ones that generate a cash flow from debt, such as loans, leases, credit card balances, or receivables. It may take the form of a bond or note, paying income at a fixed rate for a set amount of time, until maturity”—[(emphasis added)]).
Regarding claim 16, Gwozdz teaches:
a system comprising: one or more processors; and a memory in communication with the one or more processors and storing instructions that, when executed by the one or more processors, cause the one or more processors to (Gwozdz ¶0188: “According to exemplary embodiments, the System software may be implemented as one or more computer program products, for example, one or more modules of computer program instructions encoded on a computer-readable medium for execution by, or to control the operation of, data processing apparatus. The implementations can include single or distributed processing of algorithms. The computer-readable medium can be a machine-readable storage device, a machine-readable storage substrate, a memory device, or a combination of one or more them. The term “processor” encompasses all apparatus, devices, and machines for processing data, including by way of example a programmable processor, a computer, or multiple processors or computers. The apparatus can include, in addition to hardware, software code that creates an execution environment for the computer program in question, e.g., code that constitutes processor firmware, a protocol stack, a database management system, an operating system, or a combination of one or more of them”; see also Gwozdz ¶0190: “ A computer may encompass all apparatus, devices, and machines for processing data, including by way of example a programmable processor, a computer, or multiple processors or computers. It can include, in addition to hardware, code that creates an execution environment for the computer program in question, e.g., code that constitutes processor firmware, a protocol stack, a database management system, an operating system, or a combination of one or more of them”).
With respect to the remaining limitations in claim 16, although varying in scope, the remaining limitations of claim 16 are substantially the same as the limitations of claim 1, respectively. Thus, claim 16 is rejected using the same reasoning and analysis as claim 1 above.
Regarding claims 17–19, although varying in scope, the limitations of claims 17–19 are substantially the same as the limitations of claims 2 and 5–6, respectively. Thus, claims 17–19 are rejected using the same reasoning and analysis as claims 2 and 5–6 above, respectively.
Regarding claim 20, Yelheri teaches:
a non-transitory computer readable storage medium for tangibly storing computer program instructions capable of being executed by a computer processor, the computer program instructions defining the steps of (Yelheri ¶0271: “In an embodiment, the described methods and/or their equivalents may be implemented with computer executable instructions. Thus, in an embodiment, a non-transitory computer readable/storage medium is configured with stored computer executable instructions of an algorithm/executable application that when executed by a machine(s) cause the machine(s) (and/or associated components) to perform the method. Example machines include but are not limited to a processor, a computer, a server operating in a cloud computing system, a server configured in a Software as a Service (SaaS) architecture, a smart phone, and so on. In an embodiment, a computing device is implemented with one or more executable algorithms that are configured to perform any of the disclosed methods”).
With respect to the remaining limitations in claim 20, although varying in scope, the remaining limitations of claim 20 are substantially the same as the limitations of claim 1, respectively. Thus, claim 20 is rejected using the same reasoning and analysis as claim 1 above.
Claim 4 is rejected under 35 U.S.C. 103 as being unpatentable over Gwozdz in view of Yelheri and Goodman and further in view of Schierz et al., (US 11386075 B2), hereinafter “Schierz”.
Regarding claim 4, Gwozdz in view of Yelheri and Goodman teaches all the limitations of claim 3.
Gwozdz in view of Yelheri and Goodman does not appear to explicitly teach:
determining, by the one or more processors, the threshold value based at least in part on the trained data anomaly-detection machine learning model.
However, Schierz teaches:
determining, by the one or more processors, the threshold value based at least in part on the trained data anomaly-detection machine learning model (Schierz Fig. 6, Col. 31, lines 4–43: “As shown in FIG. 6, anomaly scores for a data sample are obtained 601 from multiple different sources. The multiple different sources that provide the anomaly scores can include, for example, any quantity and any type of anomaly detection blueprints, anomaly detection processes, and/or anomaly detection models. A level of anomaly detection rigor for identification of anomalousness of the data sample is identified 602. In some embodiments, the level of anomaly detection rigor can be specified by a user. In alternative embodiments, the level of anomaly detection rigor can be automatically determined by the anomaly detection system. In the embodiment depicted in FIG. 6, the level of anomaly detection rigor that is identified 602 is either maximum rigor or minimum rigor. As described in further detail below, maximum anomaly detection rigor sets a higher threshold for identifying anomalous data samples than minimum anomaly detection rigor. However, while the embodiment depicted in FIG. 6 identifies 602 either maximum anomaly detection rigor or minimum anomaly detection rigor, in alternative embodiments, a level of medium anomaly detection rigor can also be identified in step 602. Medium anomaly detection rigor sets a lower threshold for identifying anomalous data samples than maximum anomaly detection rigor, but sets a higher threshold for identifying anomalous data samples than minimum anomaly detection rigor. Furthermore, while the embodiment depicted in FIG. 6 identifies 602 a single level of anomaly detection rigor, in alternative embodiments, multiple levels of anomaly detection rigor may be selected, and the resulting anomalous data samples identified according to the multiple levels of anomaly detection rigor can be compared”—[wherein the anomaly detection rigor sets a threshold based on identified anomalous data samples from the anomaly detection model (i.e., machine learning model)]).
The methods of Gwozdz in view of Yelheri and Goodman, the teachings of Schierz, and the instant application are analogous art because they pertain to detection of anomalous data samples from a plurality of data samples.
It would be obvious to a person of ordinary skill in the art before the effective filing date of the invention to modify the methods of Gwozdz in view of Yelheri and Goodman with the teachings of Schierz to provide for the ability to determine the threshold based on the machine learning model. One would be motivated to do so to set different levels of anomaly detection and to compare the resulting anomalous data samples according to the levels (Schierz Col. 31, lines 24–43: “In the embodiment depicted in FIG. 6, the level of anomaly detection rigor that is identified 602 is either maximum rigor or minimum rigor. As described in further detail below, maximum anomaly detection rigor sets a higher threshold for identifying anomalous data samples than minimum anomaly detection rigor. However, while the embodiment depicted in FIG. 6 identifies 602 either maximum anomaly detection rigor or minimum anomaly detection rigor, in alternative embodiments, a level of medium anomaly detection rigor can also be identified in step 602. Medium anomaly detection rigor sets a lower threshold for identifying anomalous data samples than maximum anomaly detection rigor, but sets a higher threshold for identifying anomalous data samples than minimum anomaly detection rigor. Furthermore, while the embodiment depicted in FIG. 6 identifies 602 a single level of anomaly detection rigor, in alternative embodiments, multiple levels of anomaly detection rigor may be selected, and the resulting anomalous data samples identified according to the multiple levels of anomaly detection rigor can be compared”).
Claim 10 is rejected under 35 U.S.C. 103 as being unpatentable over Gwozdz in view of Yelheri and Goodman, and further in view of Dupont et al., (US 20120137367 A1), hereinafter “Dupont”.
Regarding claim 10, Gwozdz in view of Yelheri and Goodman teaches all the limitations of claim 1.
Gwozdz in view of Yelheri and Goodman does not appear to explicitly teach:
wherein the data anomaly-detection machine learning model comprises one or more cascade-based models, a cascade-model of the one or more cascade-models comprising a plurality of stages including a first stage associated with a first model and a first detection threshold, and a second stage associated with a second model and a second detection threshold, wherein the cascade-model progresses into the second stage to apply the second model to a second subset of the metadata only when an anomaly is detected in the first stage by applying the first model to a first subset of the metadata.
However, Dupont teaches:
wherein the data anomaly-detection machine learning model comprises one or more cascade-based models, a cascade-model of the one or more cascade-models comprising a plurality of stages including a first stage associated with a first model and a first detection threshold, and a second stage associated with a second model and a second detection threshold, wherein the cascade-model progresses into the second stage to apply the second model to a second subset of the metadata only when an anomaly is detected in the first stage by applying the first model to a first subset of the metadata (Dupont ¶0175: “A set of scoping policies [485], such as sliding windows [380] over the incoming data stream, are used in some embodiments to regulate the processing of events [100] by downstream components. The data collection component [400] collects data continuously or in batch mode from a variety of heterogeneous data sources [401], extracts their content and their metadata and stores the extraction results for access by downstream components of the system”; see also Dupont ¶0746: “In some embodiments, the model of generic tasks (such as marriage vows) may never reach task acceptance [1820] or may involve linking sub-models representing the agendas of individual members of a pair. Mutually dependent situations of this kind may be modeled to a first approximation by finite state transducers (like a FSA, but with arcs labeled by pairs), where the first element of any pair represents the cause of the transition, and the second represents the value to one or the other party”; see also Dupont ¶1034: “These parameters include: [1035] v: length of the sliding time window [380] for baseline pattern computation [1036] w: length of the sliding time window [380] for computation of the current trend (w is typically an order of magnitude smaller than v) [1037] For each observed or derived feature [2920], a threshold multiplier A to detect abnormal deviations. Another embodiment of the invention defines 2 levels of anomaly so that 2 thresholds are needed, with the lower threshold indicating suspicious, potentially abnormal observations that need to be confirmed by subsequent abnormal observations before becoming flagrant anomalies. Possible values for the threshold multiplier are given in the next section”—[wherein the extracted metadata is used downstream in multiple sub-models with 2 threshold levels before becoming flagrant anomalies]).
The methods of Gwozdz in view of Yelheri and Goodman, the teachings of Dupont, and the instant application are analogous art because they pertain to detecting anomalies in data with models.
It would be obvious to a person of ordinary skill in the art before the effective filing date of the invention to modify the methods of Gwozdz in view of Yelheri and Goodman with the teachings of Dupont to provide cascading models with varying degrees of thresholds at different stages. One would be motivated to do so to confirm the severity of the anomalies (Dupont ¶1034: “These parameters include: [1035] v: length of the sliding time window [380] for baseline pattern computation [1036] w: length of the sliding time window [380] for computation of the current trend (w is typically an order of magnitude smaller than v) [1037] For each observed or derived feature [2920], a threshold multiplier A to detect abnormal deviations. Another embodiment of the invention defines 2 levels of anomaly so that 2 thresholds are needed, with the lower threshold indicating suspicious, potentially abnormal observations that need to be confirmed by subsequent abnormal observations before becoming flagrant anomalies. Possible values for the threshold multiplier are given in the next section”).
Claims 13, 14, and 15 are rejected under 35 U.S.C. 103 as being unpatentable over Gwozdz in view of Yelheri and Goodman, and further in view of Larson et al., (US 20200366671 A1), hereinafter “Larson”.
Regarding claim 13, Gwozdz in view of Yelheri and Goodman teaches all the limitations of claim 1.
Yelheri teaches:
wherein the one or more actions associated with the account of the user comprise: modifying an access permission to the account associated with the user, delegating another entity to monitor the account of the user (Yelheri ¶0093: “The distributed computing platform 102 may be a multi-tenant and service platform operated by an entity in order to provide multiple tenants with a set of business related applications, data storage, and functionality. These applications and functionality may include ones that a business uses to manage various aspects of its operations. For example, the applications and functionality may include providing web-based access to business information systems, thereby allowing a user with a browser and an Internet or intranet connection to view, enter, process, or modify certain types of business information or any other type of information”; see also Yelheri ¶0268: “In an example, a first application may be provided with access to the snapshot data within set of fields in the base object 2704, and may be restricted from accessing the pointer within the base object 2704 and/or restricted from accessing the result within the sibling object 2708 based upon a first access privilege of the first application. A second application (or a data connector component) may be provided with access to the pointer within the base object 2704 based upon a second access privilege of the second application. The second application may use the pointer to access to the result within the sibling object 2708. The second application may be provided with access to the snapshot data within the base object 2704 or may be restricted from accessing the snapshot data within the base object 2704 based upon the second access privilege”—[(emphasis added)]).
Gwozdz in view of Yelheri and Goodman does not appear to explicitly teach:
transferring assets associated with the account of the user to an authenticated transferee.
However, Larson teaches:
transferring assets associated with the account of the user to an authenticated transferee (Larson Figs. 27A–29, ¶0137: “After selecting the GCE 320, the client application 110 may render and display an authentication introduction (intro) GUI instance 27B05 shown by FIG. 27B. FIG. 27A also includes another example where the user of client system 105A may wish to verify his/her identity for completing a money transfer using a separate mobile banking application, which is shown by GUI instance 27A05. The GUI instance 27A05 includes a GCE 27A08, which when selected by the user, may cause the application 110 to be executed to authenticate the user's identity. The mobile banking application may be integrated with the IVS 140 using a suitable API or the like. The GUI instance 27A05 also includes a text field GCE 27A11 and a GCE 27A06. The user may paste the obtained one-time identity authentication code into the text field GCE 27A11, and then select the GCE 27A06 to validate his/her identity in a same or similar manner as discussed infra with respect to GUI instances 2915A-2915D. After the user's identity is authenticated, the user may select the GCE 27A25 to complete the money transfer”; see also Larson ¶0246: “IDENTITY AND LINK ANALYSIS: The DII defines or discovers patterns of trusted user behavior by combining identity and transactional metadata with device identifiers, and connection and location characteristics. Transactions are compared against the trusted digital identity of the real user to identify anomalies that might indicate the use of stolen identity data, for example a mismatch between devices and locations or identity information usually associated with a digital identity”—[(emphasis added)]).
The methods of Gwozdz in view of Yelheri and Goodman, the teachings of Larson, and the instant application are analogous art because they pertain to identifying anomalies in data using learning models).
It would be obvious to a person of ordinary skill in the art before the effective filing date of the invention to modify the methods of Gwozdz in view of Yelheri and Goodman with the teachings of Larson to provide for transferring assets to authenticated users. One would be motivated to do so to prevent stolen identity and to ensure assets are placed in verified accounts (Larson ¶0137: “After selecting the GCE 320, the client application 110 may render and display an authentication introduction (intro) GUI instance 27B05 shown by FIG. 27B. FIG. 27A also includes another example where the user of client system 105A may wish to verify his/her identity for completing a money transfer using a separate mobile banking application, which is shown by GUI instance 27A05. The GUI instance 27A05 includes a GCE 27A08, which when selected by the user, may cause the application 110 to be executed to authenticate the user's identity. The mobile banking application may be integrated with the IVS 140 using a suitable API or the like. The GUI instance 27A05 also includes a text field GCE 27A11 and a GCE 27A06. The user may paste the obtained one-time identity authentication code into the text field GCE 27A11, and then select the GCE 27A06 to validate his/her identity in a same or similar manner as discussed infra with respect to GUI instances 2915A-2915D. After the user's identity is authenticated, the user may select the GCE 27A25 to complete the money transfer”; see also Larson ¶0246: “IDENTITY AND LINK ANALYSIS: The DII defines or discovers patterns of trusted user behavior by combining identity and transactional metadata with device identifiers, and connection and location characteristics. Transactions are compared against the trusted digital identity of the real user to identify anomalies that might indicate the use of stolen identity data, for example a mismatch between devices and locations or identity information usually associated with a digital identity”).
Regarding claim 14, Gwozdz in view of Yelheri, Goodman, and Larson teaches all the limitations of claim 13.
Gwozdz teaches:
wherein the automatically triggering, by the one or more processors and in response to the one or more anomalies, one or more actions associated with the account of the user, comprises: generating, by the one or more processors, one or more tasks in response to one or more anomalies (Gwozdz ¶0079: “In step 730, the output of the IDE can be utilized to engineer additional features. This utilizes the previously created Lume Elements, and creates new Lume Elements corresponding to the additional features. The feature engineering can be thought abstractly as indicator functions over sets of Lume Elements to create features related to specific signals, for learning and inference tasks. In the general case, the feature engineering can generate additional categorical, or descriptive text features needed for sequence labelling, or sequence learning tasks. For example, the engineering can prepare features for custom entity tagging, identify relationships, or target a subset of elements for downstream learning”—[wherein the learning tasks are generated based on the Lume elements (i.e., metadata) which is automatically by indicator function based on the system output]);
Larson teaches:
notifying, by the one or more processors, one or more of: the user, the another entity, and the authenticated transferee (Larson Figs. 7–10, ¶0118: “Example types of issues that may be auto-detected may include, for example, low light levels (e.g., as compared to a preconfigured threshold light level), fingers being too close together or spread too far apart, image capture device not being close enough to the palm (e.g., as compared to a preconfigured threshold distance), the incorrect palm/hand being in the field of view of the image capture device (e.g., the right hand/palm being in the field of view when the left hand/palm should), and/or the like. In these embodiments, suitable GUI instances may be displayed to notify the enrollee of the detected issue, and these GUI instances may include suitable GCEs that allow the enrollee to (re)perform the palm scan. When the application 110 obtains an indication of the enrollee's enrollment status from the IVS 140, the application 110 may auto-advance from the palm scan GUI instance 810 to GUI instance 905 of FIG. 9”; see also Larson Figs. 27A–29, ¶0137: “In this example, the enrollee or a third party employee/staff member may initiate the authentication procedure by performing a tap gesture 27A20 on the GCE 320. After selecting the GCE 320, the client application 110 may render and display an authentication introduction (intro) GUI instance 27B05 shown by FIG. 27B. FIG. 27A also includes another example where the user of client system 105A may wish to verify his/her identity for completing a money transfer using a separate mobile banking application, which is shown by GUI instance 27A05. The GUI instance 27A05 includes a GCE 27A08, which when selected by the user, may cause the application 110 to be executed to authenticate the user's identity”—[(emphasis added)]);
transmitting, by the one or more processors and in response to a confirmation the one or more of the user, the another entity and the authenticated transferee, the one or more tasks to the one or more of the user, the another entity and the authenticated transferee who sends the confirmation (Larson ¶0138: “FIG. 27B shows another example GUI for remote initiation of the authentication procedure. In this example, a third party platform employee may request to verify a user's identity for completing a money transfer using a separate mobile banking application, which is shown by GUI instance 27B05. The third party platform employee may enter various user data into respective text fields as shown by GUI instance 27B05, and may then select the GCE 27B28 to request identity authentication. Selection of the GCE 27B28 may cause the IVS 140 to trigger execution of the application 110 on the client system 105A for the user to perform an identity authentication procedure using the client system 105A. For example, the selection of the GCE 27B28 may cause the IVS 140 to send a Short Message Service (SMS) message to the client system 105A, which is shown by GUI instance 27B10. In this example, the text message may include a link 27B13, which when selected by the user by performing a tap gesture 27B20 on the link 27B13, may cause the application 110 to be executed to authenticate the user's identity”; see also Larson ¶0141: “In response to receipt of an indication of the user's enrollment status from the IVS 140, the application may render and display one of the GUI instances shown by FIG. 29. FIG. 29 shows an identity confirmation GUI instance 2905 that may be displayed when the user's identity has been properly authenticated by the IVS 140 and an identity confirmation failure GUI instance 2910 that may be displayed when the user's identity has not been authenticated by the IVS 140. The identity confirmation failure GUI instance 2910 indicates that the IVS 140 was unable to verify the user's identity, and includes a GCE 2925 that may allow the user to establish a communication session with an interviewer to discuss any potential issues. This may be accomplished in a same or similar manner as discussed previously with respect to FIGS. 21-25. The identity confirmation GUI instance 2905 includes a graphical object 2908 indicating a one-time authentication code that may be used by the user for identity verification purposes, and a GCE 2906 that allows the user to copy the one-time authentication code 2908, which may then be pasted into a text box or field of an online form or some other application. In other embodiments, the one-time authorization code may be sent to the client system in an SMS message or using some other messaging system/service. As examples, the one-tine authentication code 2908 may be pasted into a separate identity verification application as shown by GUI 2915 (including GUI instances 2915A, 2915B, 2915C, and 2915D), a separate application such as a banking application (see, e.g., GUI instance 27A05 of FIG. 27A), social networking application, or the like”—[wherein in the system transmits a short message service message to the client system, and based on the confirmation, the money transfer may be completed]); and
conducting, by the one or more processors, claim transferring based on the one or more tasks (Larson ¶0138: “FIG. 27B shows another example GUI for remote initiation of the authentication procedure. In this example, a third party platform employee may request to verify a user's identity for completing a money transfer using a separate mobile banking application, which is shown by GUI instance 27B05. The third party platform employee may enter various user data into respective text fields as shown by GUI instance 27B05, and may then select the GCE 27B28 to request identity authentication. Selection of the GCE 27B28 may cause the IVS 140 to trigger execution of the application 110 on the client system 105A for the user to perform an identity authentication procedure using the client system 105A. For example, the selection of the GCE 27B28 may cause the IVS 140 to send a Short Message Service (SMS) message to the client system 105A, which is shown by GUI instance 27B10. In this example, the text message may include a link 27B13, which when selected by the user by performing a tap gesture 27B20 on the link 27B13, may cause the application 110 to be executed to authenticate the user's identity”—[wherein the third party platform completes the money transfer (i.e., claim transfer)]).
The same motivation that was utilized for combining Gwozdz, Yelheri and Goodman with Larson as set forth in claim 13, is equally applicable to claim 14.
Regarding claim 15, Gwozdz in view of Yelheri, Goodman, and Larson teaches all the limitations of claim 13.
Larson teaches:
wherein the transferring assets associated with the account of the user to an authenticated transferee comprises verifying identity information of the transferee as matching with a transferee designated at the account of the user for receiving the assets (Larson Figs. 27A-29, ¶¶0137–0138: “FIGS. 27A-29 show GUIs for performing authentication procedures according to some embodiments. FIGS. 27A and 27B show examples of GUIs that may be used to start or initiate the authentication procedure. FIG. 27A shows two examples. A first example involves the home screen GUI instance 310 being used during an in-person (or in-store) authentication procedure. As discussed previously, the GUI instance 310 includes an authentication GCE 325 in the top right of the GUI instance 310. In this example, the enrollee or a third party employee/staff member may initiate the authentication procedure by performing a tap gesture 27A20 on the GCE 320. After selecting the GCE 320, the client application 110 may render and display an authentication introduction (intro) GUI instance 27B05 shown by FIG. 27B. FIG. 27A also includes another example where the user of client system 105A may wish to verify his/her identity for completing a money transfer using a separate mobile banking application, which is shown by GUI instance 27A05. The GUI instance 27A05 includes a GCE 27A08, which when selected by the user, may cause the application 110 to be executed to authenticate the user's identity. The mobile banking application may be integrated with the IVS 140 using a suitable API or the like. The GUI instance 27A05 also includes a text field GCE 27A11 and a GCE 27A06. The user may paste the obtained one-time identity authentication code into the text field GCE 27A11, and then select the GCE 27A06 to validate his/her identity in a same or similar manner as discussed infra with respect to GUI instances 2915A-2915D. After the user's identity is authenticated, the user may select the GCE 27A25 to complete the money transfer.
FIG. 27B shows another example GUI for remote initiation of the authentication procedure. In this example, a third party platform employee may request to verify a user's identity for completing a money transfer using a separate mobile banking application, which is shown by GUI instance 27B05. The third party platform employee may enter various user data into respective text fields as shown by GUI instance 27B05, and may then select the GCE 27B28 to request identity authentication. Selection of the GCE 27B28 may cause the IVS 140 to trigger execution of the application 110 on the client system 105A for the user to perform an identity authentication procedure using the client system 105A. For example, the selection of the GCE 27B28 may cause the IVS 140 to send a Short Message Service (SMS) message to the client system 105A, which is shown by GUI instance 27B10. In this example, the text message may include a link 27B13, which when selected by the user by performing a tap gesture 27B20 on the link 27B13, may cause the application 110 to be executed to authenticate the user's identity”—[wherein the system executes application 110 to authenticate the user’s identity and after the user’s identity is authenticated the money transfer is completed and wherein the user is the matched transferee designated at the account to receive the money transfer (i.e., assets)]).
The same motivation that was utilized for combining Gwozdz, Yelheri and Goodman with Larson as set forth in claim 13, is equally applicable to claim 15.
Conclusion
THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to NICHOLAS SHINE whose telephone number is (571)272-2512. The examiner can normally be reached M-F, 9a-5p ET.
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, David Yi can be reached on (571) 270-7519. 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.
/N.B.S./Examiner, Art Unit 2126
/DAVID YI/Supervisory Patent Examiner, Art Unit 2126
Prosecution Insights