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 . This action is made non-final.
This action is in response to the application and claims filed October 24, 2023. Claims 1-30 are pending in the case and have been examined. Claims 1-30 are rejected.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claim 20 is rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Claim 20 recites “generating a personalized adapter mixer based on the personalized embedding based on computing a weighted linear sum of parameters of the plurality of model adapters based on the personalized adapter mixer.” The scope of this limitation is unclear because the personalized adapter mixer appears to be both generated based on the weighted linear sum operation and also used as the basis for the weighted linear sum operation. Accordingly, it is unclear whether the personalized adapter mixer is an input to the weighted linear sum operation, an output of the weighted linear sum operation, or both.
Paragraphs 37-41 of the specification appear to describe an intended sequence in which a personalized embedding is generated, a personalized adapter mixer is generated based on the personalized embedding, and a personalized model adapter is generated using a weight linear sum based on the personalized adapter mixer, claim 20 does not clearly recite that sequence.
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.
Claim(s) 1-3, 5-10, 12-15, 21 and 30 is/are rejected under 35 U.S.C. 103 as being unpatentable over Huang, et al. (“Lorahub: Efficient cross-task generalization via dynamic lora composition.”, referred to as Huang), in view of Lv, et al. “Parameter-efficient weight ensembling facilitates task-level knowledge transfer.”, referred to as Lv).
Regarding claim 1, Huang teaches a processing system comprising:
one or more memories comprising processor-executable instructions; and
one or more processors configured to execute the processor-executable instructions and cause the processing system to (Page 1-2 Introduction and Section 2; Describes how that their process is implemented as a computer executed ML/LLM system. It discusses LoraHub learning being feasible on a CPU only machine and requiring processioning of LLM inference. It also says the work provides code. This is understood to be executed on processors, memory, instructions to be implemented on computers.):
access a machine learning model (Page 2-3 Section2: Describes accessing a machine learning model as it assumes a large language model Mθ based on transformer architecture, where the model may be encoder-decoder or decoder-only.);
access an enrollment dataset for a device (Page 2-3 Section2: Describes that for an unseen target task T`, a user furnishes a limited set of labeled examples Q, and the LoraHub system adapts the model to the target task using the example Q. The limited set of labeled examples Q corresponds to an enrollment dataset as it is task specific data used to personalize/adapt the model for the target task. The LoraHub learning may be performed on a CPU only machine, where the enrollment dataset is accessed by the computing device performing the adaption/inference.);
process an input to the machine learning model using the machine learning model in conjunction with the personalized model adapter (Page 3 Section 3 Figure 2: Describes applying the composed LoRA module m^ to the base LLM Mθ to generate an adapted/final LLM Mϕ = LoRA(Mθ, m^). The based LLM Mθ corresponds to the machine learning model, and the composed LoRA module m^ corresponds to the model adapter. When the adapted LLM Mϕ processes an input for the unseen target task T`, the input is processed using the machine learning model Mθ in conjunction with the personalized/composed LoRA adapter m^.); and
provide an output, by the device, based on the processing (Page 1 Figure 1, and Page 3 Section 3 Figure 2: Describes providing an output based on the processing as the system applies the composed LoRA module to the LLM to perform the intended task, and Figure 1 illustrates an unseen task test input being processed by LoraHub learning.).
Although Huang teaches, access a personalized model adapter generated based on the enrollment dataset and a plurality of model adapters, it does not teach access a personalized model adapter generated based on the enrollment dataset and a plurality of model adapters.
Lv teaches access a personalized model adapter generated based on the enrollment dataset and a plurality of model adapters (Page 271-272 Figure 1 and Section 2.2; Describes generating a new lightweight object Onew for a new task Tnew by weighting pre-existing lightweight objects O1…On, such as LoRA or Adapter modules, where the lightweight objects O1…On correspond to a plurality of model adapters. New lightweight object Onew is generated for the new task Tnew by determining contribution/similarity indicators Si for the pre-existing lightweight objects based on the new task examples/data and combining the pre-existing lightweight objects using softmax weighting, expressed as Equation 1 on page 271 The generated lightweight object Onew corresponds to personalized model adapter as it is generated for the new task Tnew based on the task-specific examples/data and the plurality of pre-existing LoRA/Adapter lightweight objects..).
It would have been obvious to one of ordinary skill in the art at the time of the claimed invention to have combined Huang’s LoraHub composition with Lv’s task-specific lightweight object generation. Doing so would have enabled the system to more efficiently generate suitable task specific adapter from existing adapter modules, to improve task level knowledge transfer, and maintain parameter efficient adaptation for a new task using limited task specific examples.
Regarding claim 2 Huang in view of Lv teaches the processing system of claim 1, wherein the one or more processors are configured to further execute the processor-executable instructions to cause the processing system to:
Huang further teaches generate an adapter mixer tensor based on the enrollment dataset; and
generate the personalized model adapter from the plurality of model adapters using the adapter mixer tensor (Page 2-3 Section 2, Page 4 Sections 3.2-3.2 and Figure 2; Describes generating coefficients/weights w based on few shot examples Q, and uses those weights to synthesize multiple LoRA modules into a single module m^.
LV also teaches this on pages 271-272 Section 2.2 and Figure 1; It generating a weighting/mixer vector form new task data and uses that vector to generate a new lightweight object from a plurality of lightweight objects, see equation 1 on page 271.).
Regarding claim 3, Huang in view of Lv teaches the processing system of claim 2, wherein, to generate the adapter mixer tensor, the one or more processors are configured to execute the processor-executable instructions to cause the processing system to:
Lv teaches generate an embedding tensor, wherein, to generate the embedding tensor, the one or more processors are configured to execute the processor-executable instructions to cause the processing system to process the enrollment dataset using the machine learning model; and
generate the adapter mixer tensor based on the embedding tensor (Pages 271-272 Section 2 and Figure 1; Describes generating an embedding tensor by processing the enrollment dataset using the machine learning model as it feeds examples of the valid data of the new task Tnew through the fixed pretrained model with lightweight object and obtains model generated representations, such as final layer representations, probability distribution, and output hidden states. It generates the adapter mixer tensor based on the embedding tensor as it uses the model generated representation/outputs to construct an indication vector S assessing the contribution of existing lightweight objects Tnew, and uses Softmax(S) as the weighting vector to generate the new lightweight object.).
Regarding claim 5, Huang in view of Lv teaches the processing system of claim 2.
Huang teaches wherein, to generate the personalized model adapter, the one or more processors are configured to execute the processor-executable instructions to cause the processing system to compute a weighted linear sum of parameters of the plurality of model adapters based on the adapter mixer tensor (Page 3-4 Section 3 and Figure 2.; Describes that, during the COMPOSE phase, all available LoRA modules mi are synthesized into a single module m^ using coefficients/weights {w1, w2, …, xN}, representing as m^ =
∑
i
=
1
N
w
i
x
n
i
, where wi is a scalar weight. The weights w are refined based on performance/loss on the few shot examples Q. Corresponding to generating the personalized model adapter by computing a weighted linear sum of plurality of LoRA module parameters based on the adapter mixer tensor/weight vector w.).
Regarding claim 6, Huang in view of Lv teaches the processing system of claim 2.
Huang teaches, wherein the processing system is the device (Page 2 Section 2; The LoraHub learning can be accomplished with a CPU only machine and merely requires processing LLM inference. Users with CPU capability can leverage trained LoRA modules through automated composition. This corresponds to implementing the LoraHub processing system on the same computing device that performs the claimed adapter generation and inference operations.).
Regarding claim 7, Huang in view of Lv teaches the processing system of claim 1,
wherein the one or more processors are configured to further execute the processor-executable instructions to cause the processing system to generate a merged machine learning model;, and
wherein, to generate the merged machine learning model, the one or more processors are configured to execute the processor-executable instructions to cause the processing system to adjust parameters of the machine learning model using the personalized model adapter (Pages 3-4 Section 3; Describes that, after composing and adapting the LoRA module m^, the optimum performing LoRA module is applied to the LLM Mθ, yielding the final LLM Mϕ = LoRA(Mθ, ˆm), which serves as an effectively adjusted model for the unseen task. The LoRA adjusts the LLM weight matrix in the form W0 + δW = W0 +AB, where AB defines the LoRA module. This corresponds to generating a merged/adjusted machine learning model by adjusting parameters of the machine learning model using the personalized LoRA adapter.).
Regarding claims 8-10, and 12-14 which recite substantially the same limitations as claims 1-3, and 5-7 but introduce a processor-implemented method for a device (It is understood that Huang teachings are implemented on computers comprising, CPU’s, GPU’s, memory’s, etc. to be controlled through software instructions) to execute the system limitations of claims 1-3, and 5-7, respectively and are rejected for the same reasons as described above.
Regarding claim 15, Huang in view of Lv teaches a processor-implemented method, comprising:
Huang teaches accessing a machine learning model (As described above in claim 1);
generating a plurality of model adapters for the machine learning model based on at least one training dataset (Pages 3-4 Section 3, and Figure 2; Describes generating a plurality of model adapters for the machine learning model abased on at least one training dataset as it trains LoRA modules on a variety of upstream tasks, wherein for N distinct upstream tasks it separately trins N LoRA modules, each represented as mi for task Ti);
accessing an enrollment dataset for a device (As described above in claim 1);
generating a personalized model adapter based on the enrollment dataset and the plurality of model adapters (Pages 3-4 Section 3, and Figure 2; Describes generating a personalized model adapter based on the enrollment dataset and the plurality of model adapters as it uses examples Q from a novel task T` to steer LoraHub learning, synthesizes available LoRA modules mi into a single module m^ using weights w, and refines w based on performance/loss on the few shot examples Q); and
deploying the personalized model adapter for the device (Pages 3-4 Section 3, and Figure 2; Describes that, after optimization, the optimum performing LoRA module m^ is applied to the LLM Mθ, yielding the final LLM, which serves as an adjusted model for the unseen task and is then deployed and not updated anymore.).
Regarding claim 21 which recite substantially the same limitations as claim 15 but introduce a processor-implemented method (It is understood that Huang teachings are implemented on computers comprising, CPU’s, GPU’s, memory’s, etc. to be controlled through software instructions) to execute the system limitations of claim 15, respectively, and is rejected for the same reasons as described above.
Regrading claim 30, Huang in view of Lv teaches the processing system of claim 21,
Huang teaches wherein the one or more processors configured to execute the processor-executable instructions and cause the processing system to generate a merged machine learning model by summing parameters of the machine learning model and parameters of the personalized model adapter (Pages 3-4, Section 3-3.3 ; Describes applying the optimum composed LoRA module m^ to the base LLM Mθ to yield the final adapted LLM. The LoRA updates a model weight matrix by adding the adapter update to the original model weight matrix, expressed as W0 + δW = W0 +AB , where W0 is the original model weight matrix and AB defines the LoRA module. This corresponds to summing parameters of the machine learning model with parameters of the personalized LoRA adapter to generate the merged/adapted machine learning model).
Claim(s) 4, and 11 is/are rejected under 35 U.S.C. 103 as being unpatentable over Huang, et al. (“Lorahub: Efficient cross-task generalization via dynamic lora composition.”, referred to as Huang), in view of Lv, et al. “Parameter-efficient weight ensembling facilitates task-level knowledge transfer.”, referred to as Lv), in view of Pfeiffer et al. ("Adapterfusion: Non-destructive task composition for transfer learning.", referred to as Pfeiffer).
Regarding claim 4, Huang in view of Lv teaches the processing system of claim 3,
They do not teach wherein, to generate the adapter mixer tensor, the one or more processors are configured to execute the processor-executable instructions to cause the processing system to, for each respective layer of a corresponding plurality of layers in the machine learning model, compute a similarity metric between a respective portion of the embedding tensor corresponding to the respective layer and a set of adapter keys for the respective layer.
Pfeiffer teaches wherein, to generate the adapter mixer tensor, the one or more processors are configured to execute the processor-executable instructions to cause the processing system to, for each respective layer of a corresponding plurality of layers in the machine learning model, compute a similarity metric between a respective portion of the embedding tensor corresponding to the respective layer and a set of adapter keys for the respective layer (Pages 490-491 Sections 2.2.3, 3.1, 3.2, and Figure 2; Describes that adapters are introduced at transformer layers and that AdapterFusion combines a set of N adapters by introducing Fusion parameters that learn to combine the adapters to solve a target task. The adapterFusion parameters include Key, Value, and Query matrices at each layer l, denoted Kl ).
It would have been obvious to one of ordinary skill in the art at the time of the claimed invention to have combined the teachings of Huang in view of Lv’s adapter composition system with Pfeiffer’s layer query weighting. Doing so would have enabled the system to improve adapter mixer generation by allowing it to identify and activate the most useful adapters for a given input and layer, enhancing transfer of task specific knowledge from multiple adapters.
Regarding claims 11 which recite substantially the same limitations as claim 4 but introduce a processor-implemented method for a device (It is understood that Huang teachings are implemented on computers comprising, CPU’s, GPU’s, memory’s, etc. to be controlled through software instructions) to execute the system limitations of claim 4, respectively and is rejected for the same reasons as described above.
Claim(s) 16-20, 22-26, 28, and 29 is/are rejected under 35 U.S.C. 103 as being unpatentable over Huang, et al. (“Lorahub: Efficient cross-task generalization via dynamic lora composition.”, referred to as Huang), in view of Lv, et al. “Parameter-efficient weight ensembling facilitates task-level knowledge transfer.”, referred to as Lv), in view of Zhao et al. ("Prototype-based HyperAdapter for Sample-Efficient Multi-task Tuning.", referred to as Zhao).
Regarding claim 16, Huang in view of Lv teaches the processor-implemented method of claim 15.
Although Huang in view of Lv teaches the processor-implemented method of claim 15. They do not teach wherein generating the plurality of model adapters comprises: generating an adapter coefficient based on the at least one training dataset; generating a first embedding based on processing a first exemplar, from the at least one training dataset, using the machine learning model; generating a first adapter mixer value based on the adapter coefficient and the first embedding, comprising computing a similarity metric between the adapter coefficient and the first embedding; and updating one or more parameters of a first model adapter, of the plurality of model adapters, based on the first adapter mixer value.
Zhao teaches, wherein generating the plurality of model adapters comprises:
generating an adapter coefficient based on the at least one training dataset (Pages 2-4 Section 3: Describes estimating task specific prototype embeddings from task specific training instances, and initializes task embeddings ki that learn the specific information of the i-th task);
generating a first embedding based on processing a first exemplar, from the at least one training dataset, using the machine learning model (Pages 2-4 Section 3: Describes processing a training sample through the model to obtain the last-year mean pooled hidden state h(i), and applies an instance dense retriever G, to contrast retrieval vector zi = G(hi).);
generating a first adapter mixer value based on the adapter coefficient and the first embedding, comprising computing a similarity metric between the adapter coefficient and the first embedding (Pages 2-4 Section 3, and Figure 5: Describes computing cosine similarity between the retrieval vector zi of a training sample and the task prototype/embedding ki, and uses those similarity scores to align instances with task prototypes.); and
updating one or more parameters of a first model adapter, of the plurality of model adapters, based on the first adapter mixer value (Pages 2-4 Section 3, and Figure 5: Describes generating adapter weight matrices from the task prototype/embedding ki using a hypernetwork, and trains the system using losses based on the cosine similarity relationship between the retrieval vector zi and task prototype ki. Where the generated adapter parameters are learned/updated based on the similarity based mixer value.).
It would have been obvious to one of ordinary skill in the art at the time of the claimed invention to have incorporated Huang, in view of Lv’s system with Zhao’s prototype based system. Doing so would have improved the efficiency and accuracy of generating the adapter mixer values and adapter parameters form limited training examples.
Regarding claim 17, Huang in view of Lv, in view of Zhao teaches the processor-implemented method of claim 16.
Zhao further teaches, wherein generating the adapter coefficient comprises:
generating a plurality of embeddings based on processing a set of exemplars from the at least one training dataset using the machine learning model; and
aggregating the plurality of embeddings (Pages 3-4 Section 3; Describes learning prototype embeddings for each task from training instances using a task shared encoder, where encoded instances are projected into retrieval vectors for prototype learning. For a training sample, the last layer mean pooled hidden state h(i) is obtained and an instance dense retriever G constructs retrieval vector zi. It aggregates instance level information form the same task and estimating task specific embeddings/prototypes, where the prototypes become center points of the instance level features.).
Regarding claim 18, Huang in view of Lv, in view of Zhao teaches the processor-implemented method of claim 17.
Zhao teaches aggregating the plurality of embeddings comprises clustering the plurality of embeddings to generate at least a first cluster, and
generating the adapter coefficient further comprises determining a representative value of the first cluster (Pages 4605-4606 Section 3-3.2 and Figure 1; Describes projecting encoded instance features into an embedding space using an instance dense retriever, where the retriever clusters intra-task instances and separates inter-task instances. It estimates task specific prototype embeddings from the clustered instance level features, where the prototypes are encouraged to become center points of the instance level features. Corresponding to clustering the plurality of embeddings and determining a representative task prototype/embedding ki as the adapter coefficient.).
Regarding claim 19, Huang in view of Lv, in view of Zhao teaches the processor-implemented method of claim 16, wherein updating the one or more parameters of the first model adapter comprises weighting gradients, generated based on the first embedding, using the first adapter mixer value (Pages 4605-4607 Section 3-3.3: Describes generating a retrieval vector zi form a training sample and computes a cosine similarity value f(zi * ki) between the retrieval vector zi and task prototype/embedding ki. It uses the similarity value in a SoftMax/contrastive prototype objective, such that gradient contributions generated form the training sample embedding zi are weighted according to the similarity between zi and ki.) The task prototype/embedding ki is used by hypernetwork to generate adapter weight matrices Dmi and Umi and that the model is trained using a total loss including the prototype/retriever losses. Corresponding to updating the adapter generating parameters based on gradients weighted by the similarity based adapter mixer value..
Regarding claim 20, Huang in view of Lv, in view of Zhao teaches the processor-implemented method of claim 15, wherein generating the personalized model adapter comprises:
Zhao teaches generating a personalized embedding based on processing the enrollment dataset using the machine learning model (Pages 4605-4607 Section 3-3.3: Describes generating a personalized embedding based on processing the enrollment dataset using the machine learning model as it processes task/new-task examples through the model to obtain hidden state/retrieval vector embeddings, including hi and zi = G(hi) and retrieves an adaptation embedding ka for few shot adaptation based on similarity between the retrieval vector and learned embeddings. ); and
Lv teaches generating a personalized adapter mixer based on the personalized embedding based on computing a weighted linear sum of parameters of the plurality of model adapters based on the personalized adapter mixer (Pages 271-272 Section 2.2 and Figure 1; Describes generating a personalized adapter mixer and computing a weighted linear sum of parameters of a plurality of model adapters as it generates an indicator vector S for a new task, sues SoftMax(S) as a soft selection/mixer vector, and generates the equation 1 from existing lightweight objects O1…On, including LoRA/Adapter modules. ; Huang also covers this on pages 3-4 Sections 3-3.2; Also describes synthesizing LoRA modules mi into a personalized/adapted module m^ using weights w, represented as
m
^
=
∑
i
=
1
N
w
i
×
m
i
where the weights are refined based on few shot examples Q form the unseen task).
Regarding claims 22-26, 28, and 29 which recite substantially the same limitations as claims 16-20, but introduce a processing system (It is understood that Huang teachings are implemented on computers comprising, CPU’s, GPU’s, memory’s, etc. to be controlled through software instructions) to execute the method limitations of claims 16-20, respectively and are rejected for the same reasons as described above. Specifically:
Claim 22 corresponds to claim 16’s generating an adapter coefficient, generating a first embedding, generating a first adapter mixer value, and updating parameters of a first model adapter, and is rejected for the same reasons as descried above.
Claim 23 corresponds to claim 17 and is rejected for the same reasons as descried above.
Claim 24 corresponds to claim 18 and is rejected for the same reasons as descried above.
Claim 25 corresponds to 16’s similarity metric to compute a similarity metric between the adapter coefficient and the first embedding, and is rejected for the same reasons as descried above.
Claim 26 corresponds to claim 19 and is rejected for the same reasons as descried above.
Claim 28 corresponds to claim 20’s generating a personalized based on processing the enrollment dataset using the machine learning model and generating a personalized adapter mixer based on the personalized embedding, and is rejected for the same reasons as descried above.
Claim 29 corresponds to claim 20’s computing a weighted linear sum of parameters of the plurality of model adapters based on the personalized adapter mixer, and is rejected for the same reasons as descried above.
Claim(s) 27 is/are rejected under 35 U.S.C. 103 as being unpatentable over Huang, et al. (“Lorahub: Efficient cross-task generalization via dynamic lora composition.”, referred to as Huang), in view of Lv, et al. “Parameter-efficient weight ensembling facilitates task-level knowledge transfer.”, referred to as Lv), in view of Zhao et al. ("Prototype-based HyperAdapter for Sample-Efficient Multi-task Tuning.", referred to as Zhao), in view of Pfeiffer et al. ("Adapterfusion: Non-destructive task composition for transfer learning.", referred to as Pfeiffer).
Regarding claim 27, Huang in view of Lv, in view of Zhao teaches the processing system of claim 22.
Although Huang in view of Lv, in view of Zhao teaches the processing system of claim 22. They do not teach the first adapter mixer value corresponds to a first layer of a plurality of layers of the machine learning model; and to generate the plurality of model adapters, the one or more processors configured to further execute the processor-executable instructions and cause the processing system to generate a second adapter mixer value, for a second layer of the plurality of layers, based on the first embedding.
Pfeiffer teaches, the first adapter mixer value corresponds to a first layer of a plurality of layers of the machine learning model; and
to generate the plurality of model adapters, the one or more processors configured to further execute the processor-executable instructions and cause the processing system to generate a second adapter mixer value, for a second layer of the plurality of layers, based on the first embedding (Pages 490-491. Sections 3-3.2 and Figure 2; Describes that AdapterFusion parameters including Key, Value, and Query matrices at each layer I, denoted KI, VI and QI and computes a contextual activation/mixer value sl,t at each transformer layer using sl,t =SoftMax(hl,tQl ⊗ zl,t,nKl),n ∈ {1,...,N}. Where a first mixer value sI,t+ correspond to a first transformer layer, and a second mixer value is generated for a second transformer layer based on the model representation/embedding for the input.).
It would have been obvious to one of ordinary skill in the art at the time of the claimed invention to have combined Pfeiffer’s layer wise AdapterFusion weighting into Huang in view of Lv, in view of Zhao’s system. Doing so would have enabled more fine grained selection and activation task relevant adapters at each layer and improving transfer of adapter knowledge for a given input.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. Se
US 20200104706 A1 : model adapter, personalized model tuning
US 20230196211 A1: plurality of model adapters
US 20230267307 A1: routing/mixer/layer selection
Any inquiry concerning this communication or earlier communications from the examiner should be directed to DONALD T RODEN whose telephone number is (571)272-6441. The examiner can normally be reached Mon-Thur 8:00-5:00 EST.
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, Omar Fernandez Rivas can be reached at (571) 272-2589. 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.
/D.T.R./Examiner, Art Unit 2128
/OMAR F FERNANDEZ RIVAS/Supervisory Patent Examiner, Art Unit 2128
Prosecution Insights