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 .
This action is in response to the amendment filed 4/21/2026. Claims 1-20 are pending in this action and claims 1-20 have been amended.
The 35 USC 112(b) and 35 USC 101 patent eligibility rejections are hereby withdrawn in view of the applicants’ amendment to the claims.
Claim Interpretation
Description and/or definitions of some claimed limitations are highlighted below for convenience.
[0018] Most electronic communication document file types also include metadata describing the communications therein. For example, many electronic communication document files include metadata formatted in compliance with a multipurpose internet mail extensions (MIME) standard that specifies the structure (or lack thereof) of the header fields (e.g., a “to” filed, a “from” field, a subject field, a date field, etc.) of the electronic communication documents. Given the flexible nature of the MIME standards, directory protocols have been developed to standardize the references to entities indicated in the MIME header fields across a network (such as the email network of a company subject to a discovery process). For example, lightweight directory access protocol (LDAP), a secure LDAP (LDAPS), and Active Directory (AD) have been developed to create central repositories for the entity information (e.g., name, aliases, email address, title, or other fields that describe the entity. By synchronizing the MIME fields with the corresponding LDAP(S)/AD entry, the service layer 110 is able to create a metadata file indicative of the entities associated with the electronic communication document. For example, the metadata file may be a generic .dat file that includes the LDAP(S) information and an indication of the corresponding electronic communication document that links the two files with one another. The service layer 110 may store the metadata files in the same or different data store as the corpus of documents 105.
[0023] After segmenting the unstructured text, the parser 120 may then execute a tagger 150 on the segments identified as corresponding to the header indicative of document metadata. The tagger 150 is configured to parse the metadata segments to identify the boundaries (and thus the values) for particular fields of metadata. For example, the tagger 150 may be configured to detect the boundary between the “To:” field, the “cc:” field, a date, a sender, a subject line, a conversation title, etc. Given that each of these fields have a different structure, the tagger 150 may include machine learning model, such as a fully convolutional network (FCN) 152, that is able to identify the potential borders between fields of different types and lengths. In some embodiments, the FCN 152 applies an n-gram model to segment the text into n-grams of different lengths. The tagger 150 may then include a prefix dictionary 154 to classify the individual portions of the unstructured text as corresponding to particular fields. To this end, the prefix dictionary may include a list of fields associated with an electronic communication document. Each field in the prefix dictionary 154 may include a list of prefixes that indicate the subsequent is likely indicative of a value for that field. For example, an entry in the prefix dictionary 154 for the subject line may include the prefixes of “RE:,” or “FWD:.” Similarly, an entry in the prefix dictionary 154 for the sender field may include the prefix of “From:.” Accordingly, after detecting the beginning boundary of a field, the tagger 150 may analyze the subsequent characters to identify a prefix included in the prefix dictionary 154 for a particular field
[0028] Generally, the entries in the metadata file correspond to a top-level segment of an electronic communication document. In one example, the entry for a particular electronic communication document includes indications of an entity in a From: field, one or more entities in a To: field, a date and/or time, a document identifier, and/or other types of metadata. Accordingly, after the segmenter 140 executes on an electronic communication document to segment out the metadata for the top-level segment, the service layer 110 may then analyze the metadata file to identify the entry to the segmented metadata to obtain the ground truth data for training the tagger 150 and/or the extractor 160.
[0033] In some embodiments, the batch processor 130 initiates the re-training process after each electronic communication document in the training set has been annotated with the ground truth data derived from the metadata files. In response, the service layer 110 may initiate a function call to the parser 120 to re-train its machine learning models using the training data derived from the corresponding metadata files.
[0046] At block 410, the computing system applies parser (such as the parser 120 of FIGS. 1 and 2) to the electronic communication documents included in the batch of electronic communication documents to identify unstructured text indicating one or more entities. In some embodiments, the parser is partially-trained based on electronic communication documents not included in the corpus of documents (such as a publicly available corpus of documents) before the parser is applied at block 410. The parser may include (1) a segmenter (such as the segmenter 140 of FIG. 2) configured to segment portions of an electronic communication document that indicates document metadata from portions of the electronic communication document associated with document content; (2) a tagger (such as the tagger 150 of FIG. 2) configured to predict boundaries between fields indicated by the document metadata for the electronic communication document; and/or (3) an extractor configured to identify entities indicated by particular fields identified by the tagger. For example, in some embodiments, the segmenter includes a recurrent neural network (RNN) (such as an RNN that includes gated recurrent units (GRUs)) and conditional random fields (CRF) model, the tagger includes a fully convolutional network (FCN) and a prefix dictionary, and the extractor includes a fully convolutional network (FCN) and an RNN (such as a long short-term memory (LSTM)).
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The text of those sections of Title 35, U.S. Code not included in this action can be found in a prior Office action.
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.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
Claim(s) 1-20 are rejected under 35 U.S.C. 103 as being unpatentable over Agarwal (US PG-PUB 20220207483 A1 issued to Agarwal et al. DATE PUBLISHED 2022-06-30 hereinafter “Agarwal”) in view of Walters (20220284280 issued to Walters et al. published 2022-09-08)
With respect to claim 1, Agarwal teaches
a computer-implemented method for self-training an electronic communication document parser (see abstract), the method comprising:
obtaining, by the one or more processors, a batch of electronic communication documents from a corpus of documents (Fig. 1, step 110, [0026], Fig. 3, 340 “text files”);
applying, by the one or more processors, a parser (Fig 3, 325; “Email Processors”;
“[0030] …FIG. 3 shows a high-level overview of how extraction of the set of entities and the tokens may take place. The environment may include a plurality of modules. The input reader 305 may provide the metadata information to either the Email Processors 325 or Attachment Processors 330. The Email Processor module 325 may read the content of the text files and the metadata information in the DAT to parse the content and populate the privilege review databases. The job of Email Processor 325 may be to identify the people involved in the documents (which are called embryo entities) and the content of the documents. Based on this parsed information, the extractor module may populate the Email Chain 345 (email chain is equated with the “batch of electronic documents), Email 350, Embryo Entity 355 and Network collections 360 in the privilege review database. The extractor module may also index the content of emails in Document Content Index 335.”
to the electronic communication documents included in the batch of electronic communication documents to identify unstructured text indicating one or more entities
[0029] A set of entities may be extracted from the documents, each entity being associated with one or more of the received documents, at step 120. Also, as part of pre-processing, tokens may be extracted from each document, each token being a word or phrase from a document at step 130. Once any initial processing is complete, the privilege analysis system may begin the extraction steps 120 and 130, parsing the emails and attachments that the client has provided. The privilege analysis system may sample a percentage of the data to verify the quality of the data being parsed;
[0038] When the extractor module receives an email, the extractor's input reader may forward the record to the email processor. The email processor may fetch all the fields in the email, and the corresponding contents. Based on this information, the email processor will parse the email and produce data objects for any embryo entities associated with the email (e.g. sender and recipient), a network data object containing the sender and recipient, and a document content index for the email. “
[The email processors distinguishes between the email content and email fields and extracts the filed; the “email content” is equated with the unstructured text.]
identifying, by the one or more processors, metadata in a metadata file associated with the electronic communication documents to annotate the identified unstructured text with one or more annotations, wherein the metadata file
[0053] FIG. 5 is a simplified block diagram of an embryo entity role mapping module 500, in an exemplary embodiment. In the case when the role mapper cannot map a known attorney to any of the current embryo entities, it may create a new embryo entity object based on the information provided by the client. An entity parser module may then parse the data extracted by extractor and role mapper to fill in the various fields in the embryo entity for the known attorneys. As an example, the entity parser may extract some of the following information for each embryo entity: first name; last name; middle name(s); email; and/or domain.]
includes indications of entity data for the one or more entities at a repository of entities;
[0026] FIG. 1 illustrates ….an embodiment. A processor of a computer having memory may receive documents from a document database at step 110, such as over a network. To perform the privilege review, some or all of the following data may be received as inputs: (1) a file (e.g. having a DAT format) containing metadata information about the emails and attachments; (2) text files containing extracted texts of emails and attachments; (3) a list of known attorneys along with their email addresses; (4) a list of known law firms; and/or (5) a list of privilege search terms. In an embodiment, at least the metadata file and the text files are received. Information used for parsing the metadata file may also be received. The received information may be used to read the metadata file, and extract information from the metadata file.]
[The “metadata file” is equated with the claimed “repository of entities” and “email address” of an “attorney” is an entity as claimed.]
based upon the annotations, re-training, by the one or more processors, the parser; and
applying, by the one or more processors, the re-trained parser to annotate additional electronic communication documents included in the corpus of documents.
[0002] A method to automatically classify emails. The method may include training, by a system that includes a processor and memory, a machine learning model configured to distinguishing between first entities having a first shared characteristic and second entities having a second shared characteristic using a curated data set of first entities and second entities, the first shared characteristic being mutually exclusive of the second shared characteristic. The method may also include obtaining, by the system, emails from an email database and generating, by the system, multiple entity data objects using entities identified in receiver and sender fields of the emails, each entity data object of the multiple entity data objects associated with a different entity identified in the emails. The method may further include categorizing, by the system, the multiple entity data objects into a first set of data objects and a second set of data objects using the machine learning model, the first set of data objects associated with a first category for classification of emails. The method may also include extracting, by the system, all tokens from each email, each token being a word or phrase from an email and the tokens including words corresponding to the entities identified in the emails and searching, by the system, the extracted tokens for tokens associated with the data objects of the first set of data objects. The method may further include identifying, by the system, the emails that include the extracted tokens that are associated with the data objects of the first set of data objects and identifying, by the system, a particular data object of the first set of data objects to which an identified email corresponds in response to the identified email including an extracted token that is associated with a multiple data objects of the first set of data objects. In some embodiments, the identifying may include calculating a joint distance for each of the multiple data objects of the first set of data objects, the joint distance for one of the multiple data objects including a sum of minimum graph distances from the one of the multiple data objects to each entity identified in the receiver and sender fields of the identified email and identifying the particular data object in response to the particular data object including a smallest joint distance, the smallest joint distance including the fewest degrees of separation between the particular data object and each entity identified in the receiver and sender fields of the identified email. The method may also include automatically classifying, by the system, the identified email in the first category in response to identifying the particular data object of the first set of data objects to which an identified email corresponds.
[0039] To extract tokens from the received documents, a paragraph extraction module may be used in an exemplary embodiment. This paragraph extraction module iterates over all the documents in the data set.
Agarwal, while teaches the step of annotating data set for use by a parser (i.e., using the paragraph extraction module iteratively for addition and/or all the documents), it does not explicitly indicate a re-trained parser that operates iteratively to annotate additional electronic communication documents included in the corpus of documents as recited in clam 1.
With respect to Claim 1, Walters (20220284280 issued to Walters et al. published 2022-09-08)
teaches to train a ML model iteratively
[0075] At step 520, the computing device may determine whether to continue or stop the iterative training process for the model. This determination may include comparing the predicted second set of labels with additional sets of labels provided by a user for the second set of data samples. Examples of such a comparison were discussed in connection with FIG. 1 and FIGS. 4A-4C. Moreover, based on the comparison, one or more counts may be determined. The one or more counts may indicate how many instances the predicted second set of labels differ from the additional sets of labels provided by the user and/or may indicate how many instances the predicted second set of labels match the additional sets of labels provided by the user 105. Determining whether to continue or stop the iterative training process for the model may be based on the one or more counts. Examples of the one or more counts were discussed in connection with FIG. 1. If the computing device determines to stop the iterative training process, the method may proceed to step 530, which begins the branch of the method 500 where the user may no longer manually labels data samples. If the computing device determines to continue the iterative training process, the method may proceed to step 525, which continues the branch of the method 500 where the user may manually label data samples.
[0076] At step 525, the computing device may repeat training of the model for another set of data samples. Repeating the training may include performing steps similar to steps 505-515 based on the other set of data samples. In this way, an indication of a set of labels for the other set of data samples may be received, the model may be trained based on the other set of data samples and the set of labels for the other set of samples, and a predicted set of labels for the other set of data samples may be generated.
With respect to claim 1, it would have been obvious to a person of ordinary skill in the art prior to filing of invention to combine the teachings of Walters in Agarwal because Walters identifies the necessity of training a machine learning model (see Walters, par. [0002]), and
[0002] Implementing a machine-learning model so that it is suitable for its intended purpose may be a time consuming and challenging process. The time consuming and challenging nature of implementing a machine-learning model may be illustrated by the numerous difficulties in training the machine-learning model and determining whether the machine-learning model is accurate. For example, training may require training data that is of sufficient volume and that is of sufficient quality. A sufficient volume of training data may be inaccessible or may not exist. Even if a sufficient volume of training data exists and is accessible, the training data may not be of sufficient quality. As a particular example, if the training is performed based on labeled training data, the quality of the labels may depend on both whether enough of the labels are correct and whether the labels are correct or incorrect in a consistent manner Ensuring that the training data satisfies both conditions of correctness and consistency may be time-intensive. Even if the training data is of sufficient volume and of sufficient quality, the training may be time intensive to perform. Once the machine-learning model is trained, determining whether the machine-learning model's output is accurate may bring even further challenges. Determining whether the machine-learning model's output is accurate may be part of a process for validating the machine-learning model. Additional data, which is different from the training data, is often needed to perform the process for validating the machine-learning model. This additional data may be inaccessible or may not exist. The validation may require some basis for determining whether the data output by the machine-learning model is accurate, and may be time intensive to perform. The above examples are only some of the difficulties that may illustrate the time consuming and challenging process of implementing a machine-learning model.
and provides solutions to the training the ML model to improve the quality of data by making the output data more accurate. See Walters, par. [0004].
[0004] Aspects described herein may address the above-mentioned challenges and difficulties, and generally improve the quality and quantity of data that is available for training a machine-learning model. Further, aspects described herein may address one or more challenges and difficulties in labeling data, training a machine-learning model using labeled data, determining an accuracy of the machine-learning model, and/or using output of the machine-learning model to generate synthetic data. The synthetic data, for example, may be used to train another machine-learning model, used to validate another machine-learning model, or the like.
[0017] By way of introduction, aspects discussed herein may relate to methods and techniques for labeling data, training a machine-learning model based on labeled data, and generating synthetic data based on predicted labels output by the machine-learning model. The methods and techniques described herein, and/or various combinations of the features described herein, may improve data labeling processes, processes for training a machine-learning model, processes for determining accuracy of a machine-learning model, and/or processes for generating synthetic data. Further, by improving the above processes, the ability to train and/or validate other machine learning models may be improved (e.g., by increasing the availability of synthetic data).
With respect to claim 2 (the computer-implemented method of claim 1, wherein applying the parser comprises: applying, by the one or more processors, a partially-trained email parser that was trained based on electronic communication documents not included in the corpus of documents), Agarwal teaches an iterative process updating entities. See Agarwal [0025]
[0025] Other features that improve the accuracy of the improved privilege analysis systems and methods are described herein. For example, a role predictor feature may utilize a privilege list received that includes a plurality of known attorney entities. The plurality of known attorney entities may be a subset of the extracted entities, which may also include a set of unknown role entities. Feature vectors may be determined for each of the entities based on the extracted tokens of the documents associated with each entity. The determined feature vectors of the known attorney entities may be compared with determined feature vectors of each unknown role entity to generate a role prediction for each unknown role entity, the role prediction having a legal value or other/non-legal value. By identifying additional legal entities using role prediction, better accuracy may be attained using the systems and methods described herein. Documents that include a reference to at least one of any known attorney entity and any unknown role entity having a role prediction value of legal may be identified as potentially privileged, based on the number of entity tokens included in the identified documents. Other features may include using a method to extract entities from received documents based on embryo entities using name variant generation and a comparison of the tokens associated with the embryo entities, a disclaimer removal tool that reduces the amount of searching needed, and an iterating process that updates a search when additional name variants are added to an entity.
With respect to claim 3, (the computer-implemented method of claim 1, wherein the parser comprises: a segmenter configured to segment portions of an electronic communication document that indicates document metadata from portions of the electronic communication document associated with document content; a tagger configured to predict boundaries between fields indicated by the document metadata for the electronic communication document; and an extractor configured to identify entities indicated by particular fields identified by the tagger), Walters teaches the generation of predicted labels. See Walters, abstract.
With respect to claim 4 (the computer-implemented method of claim 3, wherein re-training the parser comprises: executing, by the one or more processors, the segmenter to segment the electronic communication document into component communication segments and to identify the portions of the communication segments that indicate the document metadata; identifying, by the one or more processors, an entry in the metadata file corresponding to a top-level segment of the electronic communication document; annotating, by the one or more processors, the unstructured text of the electronic communication document based upon metadata included in the entry in the metadata file; and training, by the one or more processors, the tagger and the extractor based upon the annotated metadata, Agarwal teaches extraction of entities at high-level), See Agarwal, par. [0030].
[0030] FIG. 3 is a simplified block diagram of an example environment 300 for reviewing large databases of electronic communications to identify communications that are potentially privileged, in an embodiment. FIG. 3 shows a high-level overview of how extraction of the set of entities and the tokens may take place. The environment may include a plurality of modules. The input reader 305 may provide the metadata information to either the Email Processors 325 or Attachment Processors 330. The Email Processor module 325 may read the content of the text files and the metadata information in the DAT to parse the content and populate the privilege review databases. The job of Email Processor 325 may be to identify the people involved in the documents (which are called embryo entities) and the content of the documents. Based on this parsed information, the extractor module may populate the Email Chain 345, Email 350, Embryo Entity 355 and Network collections 360 in the privilege review database. The extractor module may also index the content of emails in Document Content Index 335.]
Claim 5 is rejected under same rationale as applied to claim 4. Claim 5 is directed to the computer-implemented method of claim 4, wherein annotating the metadata of the electronic communication document comprises: identifying, by the one or more processors, a plurality of entries in the metadata file respectively corresponding to electronic communication documents in which the communication segment is a top-level segment; and annotating, by the one or more processors, the unstructured text of the communication segments using the respective entry in the metadata file.
With respect to claim 6 (the computer-implemented method of claim 4, wherein training the tagger and the extractor comprises: comparing, by the one or more processors, the metadata of the communication segments to the metadata file to identify that a communication segment does not correspond to an entry in the metadata file; and excluding, by the one or more processors, the electronic communication document from a training set used to train the tagger and the extractor), see Agarwal, par. [0137].
With respect to claim 7 (the computer-implemented method of claim 3, further comprising: re-training, by the one or more processors, at least one of the segmenter, the tagger, or the extractor based upon human-applied annotations), see Agarwal, [0108].
[0108] In accordance with an exemplary embodiment, the accuracy of privilege review may be improved by identifying legal entities that were not previously identified. This may be performed using an entity role detector, at step 140 of FIG. 1. FIG. 9 illustrates an example method 900 for performing role prediction of entities. An entity may be assigned a legal role if the entity is an attorney. An entity may also be assigned a legal role if the entity is a non-attorney that is acting in a legal capacity to confer privilege in their communications. As stated previously, a privilege list may be received that includes a plurality of known attorney entities at step 905. The plurality of known attorney entities may be a subset of the extracted entities, which may also include a set of unknown role entities. For a given entity “ent,” some of the following attributes may be used: [0109] ent.emailsSent: The set of emails sent by ent. [0110] ent.role: The role of an entity, which can take one of several values (e.g., ent.role=LEGAL, NULL, or a different value). [0111] ent.roleStatus: How the role of an entity was obtained (e.g., ent.roleStatus=PREDICTED, provided by a user, etc.).
Claim 8 (the process of claim 7, wherein: the segmenter includes a recurrent neural network (RNN) and conditional random fields (CRF) model; and re-training the segmenter comprises re-training, by the one or more processors, at least one of the RNN or the CRF model. ), claim 9 (the computer-implemented method of claim 7, wherein: the tagger includes a fully convolutional network (FCN) and a prefix dictionary; and re-training the tagger comprises at least one of re-training, by the one or more processors, the FCN or updating, by the one or more processors, the prefix dictionary), and claim 10 (the computer-implemented method of claim 7, wherein: the extractor includes a fully convolutional network (FCN) and a recurrent neural network (RNN); and re-training the extractor comprises at least one of re-training, by the one or more processors, the FCN or the RNN. ) are directed to the use of several generic tools such as RNN, FCN etc., for retraining a model. With respect to claims 8 and 10, see Walters. Par. [0021].
Walters [0021] The model 115 may be any suitable machine-learning model that is configured to be used to generate predicted labels based on one or more of the data samples 103. For example, the model 115 may be a transformer, a convolutional network architecture, a recurrent neural network architecture, a deep neural network, a Variational autoencoder (VAE), or a combination of the aforementioned model types. Examples of a suitable recurrent neural network architecture include a long short-term memory (LSTM) and a Gated Recurrent Unit (GRU). Additionally, the model 115 itself may not be configured to generate the predicted labels themselves. The model may be configured to generate data indicative of predicted labels. The server 110 may process the data indicative of predicted labels, which was generated by the model 115, to translate or convert that data to a more human-readable form (e.g., translate or convert the data generated by the model 115 to a text string that provides the predicted labels in the English language).
[0022] The synthetic data generator 120 may be configured to generate synthetic data samples 130. The synthetic data generator 120 may include one or more machine learning models (e.g., one or more neural networks) that are trained to generate one or more synthetic data samples 130. The one or more machine-learning models of the synthetic data generator 120 may be trained based on training data 123. The training data 123 may include data different from the data samples 103, but may be of the same type as the data samples 103 (e.g., if the data samples 103 include textual data, the training data 123 may include additional textual data; if the data samples 103 include image data, the training data 123 may include additional image data). Further, the training based on the training data 123 may have been performed prior to the server 110 receiving the data samples 103. In this way, the synthetic data generator 120 may be pre-configured and waiting to receive input for generating synthetic data at a time when the server 110 receives the data samples 103.
[0037] The iterative training process may include training the model 115 using the first modified set of the data samples. For example, the model 115 may be trained based on the example modified data sample 210, and/or the additional example modified data sample 225 and the set of labels 230. In this way, the model 115 is trained based on the first set 103-1 of the data samples 103, but in a way that does not directly use the first set 103-1 of the data samples 103 in the training process. The model 115 may be configured to predict labels associated with particular formats of data. For example, the model 115 may be trained to predict labels associated with email data. Consequently, the model 115 may be trained using modified data samples that are commonly formatted according to the particular configuration of the model 115 (e.g., all modified data samples may be formatted as email data). The technique used for training the model 115 may be any suitable training technique and may depend on the type of model being implemented. For example, a training technique for a transformer may be different from a training technique for a convolutional network, and a training technique for a recurrent neural network architecture may be different from both training techniques for the transformer and the convolutional network.
With respect to claim 9, it would have been obvious to use a prefix dictionary, for instance, to store the tokens extracted from emails, in a prefix dictionary because storing prefixes for a group of tokens would have optimize the use of memory space and thus improve the processing time involving the stored prefixes.
Claim 11-19 are essentially the same as claims 1-10 except that they are directed to a machine rather than a method and therefore rejected under the same rationale as applied to claims 1-10 above.
Claim 20 is essentially the same as claim 1 except that it is directed to a machine rather than a method and therefore rejected under the same rationale as applied to claim 1 above.
Response to Arguments
Applicant’s arguments with respect to claims 1-20 have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). 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.
Contact Information
Any inquiry concerning this communication or earlier communications from the examiner should be directed to HOSAIN T ALAM whose telephone number is (571)272-3978. The examiner can normally be reached Mon-Thu, 8:00 - 4:30.
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.
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.
/HOSAIN T ALAM/Supervisory Patent Examiner, Art Unit 2132
Prosecution Insights