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 .
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 13-21 and 23-24 are rejected under 35 U.S.C. 101 because the claimed invention is directed to non-statutory subject matter.
The claims 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. The claims are directed to the abstract idea of translating an arbitrary product name to a standardized product descriptor, as explained in detail below.
The limitations, as drafted, is a process that, under its broadest reasonable interpretation, covers performance of the limitation in the mind but for the recitation of generic computer components. That is, other than reciting “various elements” nothing in the claim element precludes the steps from practically being performed by mental processing. For example, the language, receiving a product name (can be done by a user receiving specific data), generating product descriptor (can be done by a user generating specific data), retrieving candidate product descriptors (can be done by a user retrieving specific data), performing a similarity search (can be done by a user comparing data) and selecting a candidate standardized product descriptor (can be done by selecting specific data). The present claim language under its broadest reasonable interpretation, covers performance of mental processing and recites generic computer components, which all falls within the “Mental Processes” grouping of abstract ideas. Accordingly, the claim recites an abstract idea.
This judicial exception is not integrated into a practical application. In particular, the claim only recites additional elements which are recited at a high-level of generality (i.e., as a generic processor performing a generic computer function) such that it amounts no more than mere instructions to apply the exception using a generic computer component. Accordingly, this additional element does not integrate the abstract idea into a practical application because it does not impose any meaningful limits on practicing the abstract idea.
The claim does not include additional elements 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 amounts to no more than mere instructions to apply the exception using a generic computer component. Mere instructions to apply an exception using a generic computer component cannot provide an inventive concept. The claims are not patent eligible.
The dependent claims recite similar language such as translating, receiving, parsing, retrieving, receiving, generating, selecting, searching, transmitting, storing, translating and calculating data, which is all mental processing and non-statutory.
Claim Rejections - 35 USC § 102
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
Claim(s) 13-14 and 16-32 is/are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Kundu et al. (PGPUB 2024/0071047), hereinafter referenced as Kundu.
Regarding claim 13, Kundu discloses a computer-implemented method for translating an arbitrary product name to a standardized product descriptor, the computer-implemented method comprising:
receiving, by a domain-specific translation model, an arbitrary product name (paragraph [0033, 0032 0077]- standardized form, as the canonical reference ontology based on the standard schema, based on his product information form, as the product descriptors, comprising all the information on the form, each form domain-specific);
generating, by the domain-specific translation model, a plausible standardized product descriptor corresponding to the arbitrary product name (paragraph [0051,0005]- generative, GPT-3 model, generating variants for each standard form key);
retrieving, by the domain-specific translation model, a plurality of candidate standardized product descriptors from data storage based on the plausible standardized product descriptor (the pairs transmitted as a labeled training set to train the model; paragraphs [0005, 0022-0034]); and
selecting, by the domain-specific translation model, a candidate standardized product descriptor from the plurality of candidate standardized product descriptors (Aspects of the disclosure provide a computerized method and system for mapping key character strings of a form document to standardized keys of one of several form types. The disclosure describes receiving a set of input key-value pairs associated with a form and determining a subset of candidate form types from a set of form types based on that set of input key-value pairs. A set of standard keys associated with the determined subset of candidate form types is combined with the set of input key-value pairs to generate a set of input key-standard key pairs. The set of input key-standard key pairs is then narrowed using a narrowing rule. A trained model is then used to generate ranking scores for each input key-standard key pair of the narrowed set of pairs and, using the generated ranking scores, each input key is mapped to a standard key; p. 0018, 0043-0044, 0069-0074).
Regarding claim 14, Kundu discloses a method wherein the domain-specific translation model is trained to translate arbitrary product names to standardized product descriptors based on a plurality of synthetic input-output pairs (paragraph [0041, 0051-0062, 0072-0075]- selected standard key, as the output, from the pair).
Regarding claim 16, Kundu discloses a method wherein generating the plausible standardized product descriptor corresponding to the arbitrary product name comprises:
receiving a plurality of data files comprising the plurality of synthetic input-output pairs (paragraph [0041, 0051-0062, 0072-0075]- selected standard key, as the output, from the pair); and
generating the plausible standardized product descriptor based on a plurality of plausible proprietary naming variants in the plurality of synthetic input-output pairs (paragraph [0051, 0069, 0005, 0022-0034]-generative, GPT-3 model, generating variants for each standard form key).
Regarding claim 17, Kundu discloses a method wherein selecting the candidate standardized product descriptor from the plurality of candidate standardized product descriptors comprises performing a vector-based search of the plurality of candidate standardized product descriptors (Further, in some examples, the key mapping model 274 is trained to generate ranking scores of input key-standard key pairs as a key pair rank model 134 in a system such as system 100. Further, in some such examples, the key mapping model 274 is used to generate the form type model 126 that is used in systems such as system 100. In such examples, the key mapping model 274 is used to obtain vector representations for multiple keys (key vectors) from the form 102. A key vector of a key is a set of numerical values that is generated using the key and an encoding process. The result of the encoding process is a key vector with numerical values that are based on details of the key (e.g., which characters are included in the key and in which order) and the combination of which is effectively unique to that particular key, meaning that the precise key vector generated from a key will never be generated using a different key. Such encoding processes are often configured to provide key vectors that are indicative of similarities of the keys from which they are generated, such that key vectors of two keys with similar characters and/or structures have more similar sets of numerical values than key vectors of two keys with very different characters and/or structures; p. 0057-0058, 0070, 0096).
Regarding claim 18, Kundu discloses a method wherein performing the vector- based search comprises comparing each candidate standardized product descriptor of the plurality of candidate standardized product descriptors against the arbitrary product name, wherein the plurality of candidate standardized product descriptors comprise entries in a canonical reference ontology (CRO; paragraph [0033, 0032 0077]- standardized form, as the canonical reference ontology based on the standard schema, based on his product information form, as the product descriptors, comprising all the information on the form, each form domain-specific).
Regarding claim 19, Kundu discloses a method further comprising transmitting the candidate standardized product descriptor to a computing device to display the candidate standardized product descriptor (In some examples, the FR service 602 analyzes a custom form document (e.g., a bank statement form) and extracts key-value pairs 618, such as a person's Social Security Number (SSN) and an associated key ‘SSN’ as displayed on the form. The extracted key-value pairs 618 are provided to the connector of the Schema Mapping API 604 (e.g., the key mapping engine 110). In the connector 604, the key-value pairs 618 are converted to “Schema Matching API contracts” at 608, which are data structures that are compatible with the Schema Matching API 610. Additionally, or alternatively, the Form Type Detection module 606 of the connector 604 identifies one or more candidate form types of the custom form doc based on the extracted key-value pairs at 620).
Regarding claim 20, Kundu discloses a method further comprising:
receiving proprietary data for canonical mapping (paragraph [0033, 0032 0077]- standardized form, as the canonical reference ontology based on the standard schema, based on his product information form, as the product descriptors, comprising all the information on the form, each form domain-specific);
receiving one or more corrected standardized product descriptors based on the candidate standardized product descriptor (paragraph [0041, 0051-0062, 0072-0075]- selected standard key, as the output, from the pair);
mapping the proprietary data to the one or more corrected standardized product descriptors (paragraph [0033, 0032 0077]- standardized form, as the canonical reference ontology based on the standard schema, based on his product information form, as the product descriptors, comprising all the information on the form, each form domain-specific); and
storing the mapping of the proprietary data to the one or more corrected standardized product descriptors in a canonical reference ontology (CRO; paragraph [0033, 0032 0077]- standardized form, as the canonical reference ontology based on the standard schema, based on his product information form, as the product descriptors, comprising all the information on the form, each form domain-specific).
Regarding claim 21, Kundu discloses a method for translating an arbitrary product name to a standardized product descriptor, the computer-implemented method comprising:
receiving, by a domain-specific translation model, an arbitrary product name (paragraph [0033, 0032 0077]- standardized form, as the canonical reference ontology based on the standard schema, based on his product information form, as the product descriptors, comprising all the information on the form, each form domain-specific);
generating, by the domain-specific translation model, a plausible standardized product descriptor corresponding to the arbitrary product name (paragraph [0041, 0051-0062, 0072-0075]- selected standard key, as the output, from the pair);
retrieving, by the domain-specific translation model, a plurality of candidate standardized product descriptors from a canonical reference ontology (CRO) based on the plausible standardized product descriptor (paragraph [0033, 0032 0077]- standardized form, as the canonical reference ontology based on the standard schema, based on his product information form, as the product descriptors, comprising all the information on the form, each form domain-specific);
performing, by the domain-specific translation model, a similarity search to compare each candidate standardized product descriptor against the arbitrary product name (FIG. 2 is a block diagram illustrating a system 200 configured for performing a training process of a trained key mapping model 274, such as a form type model 126 and/or a key pair rank model 134. A trained key mapping model 274 is a model that is trained to classify or otherwise determine a degree of similarity between a keys of different forms, generally. Such a trained key mapping model 274 can then be utilized to identify candidate form types 128 as a form type model 126. This is achieved by the form type model 126 determining standard keys 116 from form types 114 that are similar to the input keys 106 of a form 102 being analyzed and then identifying the form types 114 that are most similar to the form 102 based on those identified key relationships. Alternatively, or additionally, in some examples, a trained key mapping model 274 is utilized as a key pair rank model 134 to generate ranking scores 136 associated with pairs of keys that include an input key 106 paired with a standard key 116. In some examples, the system 200 trains the key pair rank model 134 of a system 100 prior to the system 100 being used to generate input key-standard key mappings 140 as described herein. Further, in some examples, the system 200 trains and/or fine-tunes the key pair rank model 134 using at least a portion of the described training process in parallel with the operations of the system 100 (e.g., the form key mapping model fine-tuning using customer data 266; p. 0045, 0050, 0057); and
selecting, by the domain-specific translation model, a candidate standardized product descriptor from the plurality of candidate standardized product descriptors based on the similarity search (paragraph [0033, 0032 0077]- standardized form, as the canonical reference ontology based on the standard schema, based on his product information form, as the product descriptors, comprising all the information on the form, each form domain-specific).
Regarding claim 22, Kundu discloses a method wherein the domain-specific translation model comprises a transformer-based model trained on synthetic input-output pairs generated by a generative artificial intelligence (GAI) model (paragraph [0033, 0032 0077]- standardized form, as the canonical reference ontology based on the standard schema, based on his product information form, as the product descriptors, comprising all the information on the form, each form domain-specific).
Regarding claim 23, Kundu discloses a method further comprising:
receiving user feedback confirming or correcting the selected candidate standardized product descriptor (the system 200 uses form key mapping model fine-tuning 266 processes using customer data. In some examples, this fine-tuning 266 is performed after the trained model has been used by a customer in a runtime system such as system 100. In such examples, input key-standard key mappings 140 that have been generated by the runtime system are used as labeled input key-standard key mapping 268 training data to further improve the next version of the model 274. Additionally, in some examples, user feedback from the customer is also collected and used during the fine-tuning 266 to determine the content of the mappings that are used as training data; p. 0055, 0105); and
storing the user feedback as labeled real-world data for retraining the domain-specific translation model (the system 200 uses form key mapping model fine-tuning 266 processes using customer data. In some examples, this fine-tuning 266 is performed after the trained model has been used by a customer in a runtime system such as system 100. In such examples, input key-standard key mappings 140 that have been generated by the runtime system are used as labeled input key-standard key mapping 268 training data to further improve the next version of the model 274. Additionally, in some examples, user feedback from the customer is also collected and used during the fine-tuning 266 to determine the content of the mappings that are used as training data; p. 0055, 0105).
Regarding claim 24, Kundu discloses a method wherein performing the similarity search comprises:
transforming the arbitrary product name into an encoded representation (In some examples, the key mapping model 274 is trained to generate ranking scores of input key-standard key pairs as a key pair rank model 134 in a system such as system 100. Further, in some such examples, the key mapping model 274 is used to generate the form type model 126 that is used in systems such as system 100. In such examples, the key mapping model 274 is used to obtain vector representations for multiple keys (key vectors) from the form 102. A key vector of a key is a set of numerical values that is generated using the key and an encoding process. The result of the encoding process is a key vector with numerical values that are based on details of the key (e.g., which characters are included in the key and in which order) and the combination of which is effectively unique to that particular key, meaning that the precise key vector generated from a key will never be generated using a different key. Such encoding processes are often configured to provide key vectors that are indicative of similarities of the keys from which they are generated, such that key vectors of two keys with similar characters and/or structures have more similar sets of numerical values than key vectors of two keys with very different characters and/or structures.);
transforming each candidate standardized product descriptor into a respective representation (paragraph [0033, 0032 0077]- standardized form, as the canonical reference ontology based on the standard schema, based on his product information form, as the product descriptors, comprising all the information on the form, each form domain-specific); and
calculating similarity scores between the arbitrary product name and each candidate standardized product descriptor (FIG. 2 is a block diagram illustrating a system 200 configured for performing a training process of a trained key mapping model 274, such as a form type model 126 and/or a key pair rank model 134. A trained key mapping model 274 is a model that is trained to classify or otherwise determine a degree of similarity between a key of different forms, generally. Such a trained key mapping model 274 can then be utilized to identify candidate form types 128 as a form type model 126. This is achieved by the form type model 126 determining standard keys 116 from form types 114 that are similar to the input keys 106 of a form 102 being analyzed and then identifying the form types 114 that are most similar to the form 102 based on those identified key relationships. Alternatively, or additionally, in some examples, a trained key mapping model 274 is utilized as a key pair rank model 134 to generate ranking scores 136 associated with pairs of keys that include an input key 106 paired with a standard key 116. In some examples, the system 200 trains the key pair rank model 134 of a system 100 prior to the system 100 being used to generate input key-standard key mappings 140 as described herein. Further, in some examples, the system 200 trains and/or fine-tunes the key pair rank model 134 using at least a portion of the described training process in parallel with the operations of the system 100 (e.g., the form key mapping model fine-tuning using customer data 266; p. 0045, 0050, 0057).
Regarding claim 25, Kundu discloses a system for creating and continuously improving a domain-specific translation model, the system comprising:
a canonical reference ontology (CRO) storing standardized product descriptors for a domain (paragraph [0033, 0032 0077]- standardized form, as the canonical reference ontology based on the standard schema, based on his product information form, as the product descriptors, comprising all the information on the form, each form domain-specific);
an artificial intelligence (AI) model configured to generate synthetic training data based on the CRO (paragraph [0033, 0032 0077]- standardized form, as the canonical reference ontology based on the standard schema, based on his product information form, as the product descriptors, comprising all the information on the form, each form domain-specific);
a domain-specific translation model configured to translate arbitrary product names to standardized product descriptors (paragraph [0033, 0032 0077]- standardized form, as the canonical reference ontology based on the standard schema, based on his product information form, as the product descriptors, comprising all the information on the form, each form domain-specific); and
a feedback integration module configured to incorporate user corrections into the training corpus of the domain-specific translation model (the system 200 uses form key mapping model fine-tuning 266 processes using customer data. In some examples, this fine-tuning 266 is performed after the trained model has been used by a customer in a runtime system such as system 100. In such examples, input key-standard key mappings 140 that have been generated by the runtime system are used as labeled input key-standard key mapping 268 training data to further improve the next version of the model 274. Additionally, in some examples, user feedback from the customer is also collected and used during the fine-tuning 266 to determine the content of the mappings that are used as training data; p. 0055, 0105).
Regarding claim 26, Kundu discloses a system wherein the AI model is configured to:
receive standardized product descriptors from the CRO (paragraph [0033, 0032 0077]- standardized form, as the canonical reference ontology based on the standard schema, based on his product information form, as the product descriptors, comprising all the information on the form, each form domain-specific);
generate multiple plausible proprietary naming variants for each standardized product descriptor using domain-specific prompts and heuristics (The system 200 then uses form key mapping model pre-training 256 processes to train the model 274. In some examples, the pre-training 256 processes collect public, customer-specific, or other entity-specific form documents from various sources, such as the Internet and the model is trained using key data from these form documents as training data. Further, in some examples, a FR application is applied to the form documents to extract form document keys 258 and, in some cases, the keys 258 are used with a paraphrasing generation algorithm (e.g., using GPT-3 and/or other language models) to automatically generate variants 260 of each form document key 258. In some such examples, a variant 260 of a key 258 is a word or phrase that is considered to be semantically the same as or similar to the key 258. The generated variants 260 and the extracted form document keys 258 are used as paired key data to pre-train the model to recognize variants 260 of keys 258 that are semantically the same as the keys 258; p. 0051, 0055-0056, 0062-0063); and
output synthetic input-output pairs where each input is a proprietary naming variant and each output is the corresponding standardized product descriptor (paragraph [0033, 0032 0077]- standardized form, as the canonical reference ontology based on the standard schema, based on his product information form, as the product descriptors, comprising all the information on the form, each form domain-specific).
Regarding claim 27, Kundu discloses a system further comprising a fine-tuning engine configured to periodically retrain the domain-specific translation model using both synthetic input-output pairs from the AI model and labeled real-world data from the feedback integration module (the system 200 uses form key mapping model fine-tuning 266 processes using customer data. In some examples, this fine-tuning 266 is performed after the trained model has been used by a customer in a runtime system such as system 100. In such examples, input key-standard key mappings 140 that have been generated by the runtime system are used as labeled input key-standard key mapping 268 training data to further improve the next version of the model 274. Additionally, in some examples, user feedback from the customer is also collected and used during the fine-tuning 266 to determine the content of the mappings that are used as training data; p. 0055, 0105).
Regarding claim 28, Kundu discloses a system wherein the feedback integration module is configured to:
receive user confirmations or corrections of suggested canonical references (the system 200 uses form key mapping model fine-tuning 266 processes using customer data. In some examples, this fine-tuning 266 is performed after the trained model has been used by a customer in a runtime system such as system 100. In such examples, input key-standard key mappings 140 that have been generated by the runtime system are used as labeled input key-standard key mapping 268 training data to further improve the next version of the model 274. Additionally, in some examples, user feedback from the customer is also collected and used during the fine-tuning 266 to determine the content of the mappings that are used as training data; p. 0055, 0105);
aggregate the user feedback to form a repository of real-world labeled data (train a key mapping model using a trained base language model and domain-specific text training data, wherein the domain-specific text training data is specific to a domain of form types; train the key mapping model using paired key data of form types in the domain as training data; and fine-tune the key mapping model using labeled mappings.); and
transmit the real-world labeled data to a training pipeline for improving the domain- specific translation model (train a key mapping model using a trained base language model and domain-specific text training data, wherein the domain-specific text training data is specific to a domain of form types; train the key mapping model using paired key data of form types in the domain as training data; and fine-tune the key mapping model using labeled mappings).
Regarding claim 29, Kundu discloses a method for continuously improving a domain-specific translation model, the computer-implemented method comprising:
monitoring a canonical reference ontology (CRO) for new standardized product descriptors (paragraph [0033, 0032 0077]- standardized form, as the canonical reference ontology based on the standard schema, based on his product information form, as the product descriptors, comprising all the information on the form, each form domain-specific);
detecting new standardized product descriptors (paragraph [0033, 0032 0077]- standardized form, as the canonical reference ontology based on the standard schema, based on his product information form, as the product descriptors, comprising all the information on the form, each form domain-specific);
generating synthetic training data for the new descriptors using a generative artificial intelligence (GAI) model (paragraph [0033, 0032 0077]- standardized form, as the canonical reference ontology based on the standard schema, based on his product information form, as the product descriptors, comprising all the information on the form, each form domain-specific);
collecting user feedback on translation results produced by a domain-specific translation model (The system 200 uses form key mapping model fine-tuning 266 processes using customer data. In some examples, this fine-tuning 266 is performed after the trained model has been used by a customer in a runtime system such as system 100. In such examples, input key-standard key mappings 140 that have been generated by the runtime system are used as labeled input key-standard key mapping 268 training data to further improve the next version of the model 274. Additionally, in some examples, user feedback from the customer is also collected and used during the fine-tuning 266 to determine the content of the mappings that are used as training data; p. 0055, 0105);
combining the synthetic training data and the user feedback to create an updated training corpus (The system 200 uses form key mapping model fine-tuning 266 processes using customer data. In some examples, this fine-tuning 266 is performed after the trained model has been used by a customer in a runtime system such as system 100. In such examples, input key-standard key mappings 140 that have been generated by the runtime system are used as labeled input key-standard key mapping 268 training data to further improve the next version of the model 274. Additionally, in some examples, user feedback from the customer is also collected and used during the fine-tuning 266 to determine the content of the mappings that are used as training data; p. 0055, 0105); and
retraining the domain-specific translation model with the updated training corpus (paragraph [0033, 0032 0077]- standardized form, as the canonical reference ontology based on the standard schema, based on his product information form, as the product descriptors, comprising all the information on the form, each form domain-specific).
Regarding claim 30, Kundu discloses a method wherein generating synthetic training data comprises:
prompting the GAI model with each new standardized product descriptor and domain specific guidelines (paragraphs [0041, 0042, 0047]- DNN, domain language model used for training, as prompt information, and corresponding machine learning techniques, as the heuristics);
receiving multiple proprietary naming variants from the GAI model for each new standardized product descriptor (paragraph [0033, 0032 0077]- standardized form, as the canonical reference ontology based on the standard schema, based on his product information form, as the product descriptors, comprising all the information on the form, each form domain-specific); and
creating synthetic input-output pairs pairing each proprietary naming variant with its corresponding standardized product descriptor paragraph ([0051, 0005] - generative, GPT-3 model, generating variants for each standard form key).
Regarding claim 31, Kundu discloses a method wherein collecting user feedback comprises:
presenting a suggested standardized product descriptor to a user for a given arbitrary product name (paragraph [0051,0005]- generative, GPT-3 model, generating variants for each standard form key);
receiving a confirmation or correction from the user (the system 200 uses form key mapping model fine-tuning 266 processes using customer data. In some examples, this fine-tuning 266 is performed after the trained model has been used by a customer in a runtime system such as system 100. In such examples, input key-standard key mappings 140 that have been generated by the runtime system are used as labeled input key-standard key mapping 268 training data to further improve the next version of the model 274. Additionally, in some examples, user feedback from the customer is also collected and used during the fine-tuning 266 to determine the content of the mappings that are used as training data; p. 0055, 0105); and
storing the arbitrary product name paired with the confirmed or corrected standardized product descriptor as labeled real-world data (the system 200 uses form key mapping model fine-tuning 266 processes using customer data. In some examples, this fine-tuning 266 is performed after the trained model has been used by a customer in a runtime system such as system 100. In such examples, input key-standard key mappings 140 that have been generated by the runtime system are used as labeled input key-standard key mapping 268 training data to further improve the next version of the model 274. Additionally, in some examples, user feedback from the customer is also collected and used during the fine-tuning 266 to determine the content of the mappings that are used as training data; p. 0055, 0105).
Regarding claim 32, Kundu discloses a method wherein the domain-specific translation model is retrained periodically on a scheduled basis to incorporate both newly generated synthetic data and accumulated user feedback (The system 200 uses form key mapping model fine-tuning 266 processes using customer data. In some examples, this fine-tuning 266 is performed after the trained model has been used by a customer in a runtime system such as system 100. In such examples, input key-standard key mappings 140 that have been generated by the runtime system are used as labeled input key-standard key mapping 268 training data to further improve the next version of the model 274. Additionally, in some examples, user feedback from the customer is also collected and used during the fine-tuning 266 to determine the content of the mappings that are used as training data; p. 0055, 0105).
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.
Claim(s) 15 is/are rejected under 35 U.S.C. 103 as being unpatentable over Kundu in view of Yuan et al. (PGPUB 2022/0092096), hereinafter referenced as Yuan.
Regarding claim 15, Kundu discloses a method as described above, but does not specifically teach wherein receiving the arbitrary product name comprises:
receiving text data, parsing the text data and retrieving the arbitrary product name from the parsed text data.
Yuan discloses a method wherein receiving the arbitrary product name comprises:
receiving text data (receive text; p. 0095-0098);
parsing the text data (segment; p. 0095-0098); and
retrieving the arbitrary product name from the parsed text data (product name; p. 0052 with fig. 8), to assist with information processing.
Therefore, it would have been obvious to one of ordinary skill of the art, before the effective filing date of the claimed invention, to modify the method as described above, to speed up searching and improve accuracy.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. This information has been detailed in the PTO 892 attached (Notice of References Cited).
Borrel et al. (USPN 11,100,469) discloses cross-domain collaborative data log.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JAKIEDA R JACKSON whose telephone number is (571)272-7619. The examiner can normally be reached Mon - Fri 6:30a-2:30p.
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, Daniel Washburn can be reached at 571.272.5551. 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.
/JAKIEDA R JACKSON/Primary Examiner, Art Unit 2657
Prosecution Insights