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 .
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 2/12/2026 has been entered.
Accordingly, claims 1-4, 8-9, 11-14, and 18-20 are pending in this application. Claims 1, 11, and 18 are currently amended.
Response to Arguments
Applicant’s arguments with respect to amended pending claims filed on 2/12/2026 have been fully considered. In view of the claim amendment filed, the rejection has been withdrawn. However, upon further consideration, a new ground(s) of rejection is made.
Further, regarding the new limitations recited in claims 1, 11, and 18, it is submitted that they are properly addressed by the new ground of rejection.
Furthermore, it is also submitted that all limitations in pending claims, including those not specifically argued, are properly addressed. The reason is set forth in the rejections. See claim analysis below for detail.
Specification
Applicant is reminded of the proper language and format for an abstract of the disclosure.
The abstract should be in narrative form and generally limited to a single paragraph on a separate sheet within the range of 50 to 150 words in length. The abstract should describe the disclosure sufficiently to assist readers in deciding whether there is a need for consulting the full patent text for details.
The language should be clear and concise and should not repeat information given in the title. It should avoid using phrases which can be implied, such as, “The disclosure concerns,” “The disclosure defined by this invention,” “The disclosure describes,” etc. In addition, the form and legal phraseology often used in patent claims, such as “means” and “said,” should be avoided.
The abstract of the disclosure is objected to because it exceeds 150 words.
Appropriate correction is required.
Claim Objections
Claims 1, 11, and 18 are objected to because of the following informalities: Claim 1, 11, and 18 recite “compositing, using the detected text, the first data field”. The Examiner believes that this is a typographical mistake and the Applicant meant to recite “composing, using the detected text, the first data field”.
Appropriate correction is required.
Claim Rejections - 35 USC§ 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1-4, 8-9, 11-14, and 18-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to abstract idea without significantly more.
The claims recite a process of listening … to communications, training… models, detecting…text, compositing… data field, receiving… communication, translating… data, and generating translated data, generating… communication, and transmitting… communication as recited in claim 1.
The claimed process is similar to a method of mental processes, particularly concepts performed in the human minds (including an observation, evaluation, judgement, opinion), which is one of the groupings of abstract ideas according to Prong One in Step 2A of the 2019 Patent Subject Matter Eligibility Guidance since the steps of receiving data, generating data, and transmitting communication are directed to a series of thought processes (i.e. mental processes).
Also this judicial exception is not integrated into a practical application because receiving data, generating data, and transmitting communication does not mean the processes will actually occur and result in a practical application.
The claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception. Additional elements (e.g. probability distribution tensor, error message) are directed to types of information being manipulated. The types of information being manipulated does not impose a meaningful limit on the judicial exception, such that the claims are more than a drafting effort design to monopolize exception, because the claimed steps could be performed in a same manner to achieve the same outcome with other types of information other than the ones being used in the claims.
Hence, the claims do not include additional elements or the combination of the elements are sufficient to amount to significantly more than the judicial exception and fail to integrate the judicial exception into practical application according to Prong Two in Step 2A of the 2019 Patent Subject Matter Eligibility Guidance because the claimed elements or the combination do not impose any meaningful limits on practicing the abstract idea.
Further, in view of Step 2B of the 2019 Patent Subject Matter Eligibility Guidance, it is determined that the computing elements (such as a system comprising: at least one processor; and a computer readable non-transitory storage medium storing computer program instructions) in the claim amount to no more than usage of a generic computing system having a generic computing components-- such as processor-of a generic network, which fails to provide an inventive concept or significantly more than abstract idea because the elements do not necessary improve the functional of a computing system or an improvement to a technical field since network computing is well known.
Thus, for at least the reasoning above, the pending claims are not patent eligible.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1-4, 8-9, 11-14, and 18-20 are rejected under 35 U.S.C. 103 as being unpatentable over Layton et al. (US 20220092028 A1) in view of Walters (US 2020012540 A1).
Regarding Claim 1, Layton discloses a method performed by a processor (Fig. 14; [0185]: The processing system 300 includes one or more processors that execute computer-readable instructions and non-transitory memory that stores the computer-readable instructions), said method comprising:
listening, using a shared application fabric plugin, to a plurality of communications between a first microservice and a second microservice (Fig. 16; [0215]-[0218]: the ticket management system 1604 may listen for requests to generate a new ticket (e.g., an API call requesting a new ticket)… In embodiments, the conversation system 1606 is implemented as a set of microservices that can power a chat bot);
training, during a runtime, one or more machine learning models using the plurality of communications to generate a schema mapper (Fig. 16; [0219]-[0228]: The conversation system 1606 may utilize machine learned models (e.g., neural networks) that are trained on service-related conversations to process text received from a contact and extract a meaning from the text; [0007]: the customization system may include an object schema service for providing an object definition application programming interface (API) for receiving the custom object information from the user device), the training comprising:
detecting a text that is categorized to a first data field in a first subset communication data records of the plurality of communications and categorized to second data field in a second subset of communication data records of the plurality of communications ([0229]: FIG. 17A illustrates an example schema of a contact database record 1700… The contact identifier (“ID”) 1702 may be a unique value (e.g., string or number) that uniquely identifies the contact from other contacts… the client ID 1704 defines the relationship between the contact and the client);
compositing, using the detected text, the first data field, and the second data field, a plurality of schemas used by the plurality of communications to generate one or more of a one-to-many mapping between a first generalized class to multiple specific instances or a one-to-one mapping between a second generalized class and a corresponding specific instance (Fig. 16; [0228]: In embodiments, the proprietary database(s) 1620 may store and index data records… FIGS. 17A-17C illustrate example high level schemas of contact records 1700 (FIG. 17A), client records 1720 (FIG. 17B), and ticket records 1740 (FIG. 17C); [0101]: The data-profiling model may include algorithms to determine a data type, key-value pairs, row-column data structure, statistical distributions of information such as keys or values, or other property of a data schema).
However, Layton does not explicitly teach “receiving a communication from the first microservice intended for the second microservice, wherein the communication comprises data from the first microservice for the second microservice, the data structured in a first schema having a first set of data fields with corresponding field attributes, the first schema being different from a second schema used by the second microservice; dynamically translating, using the one or more machine learning models and during the same runtime as training the one or more machine learning models of the schema mapper, the data in the first schema to generate translated data restructured in the second schema having second set of data fields with corresponding field attributes; generating a modified communication by including the translated data restructured in the second schema; and transmitting the modified communication to the second microservice”.
On the other hand, in the same field of endeavor, Walters teaches
receiving a communication from the first microservice intended for the second microservice (Fig. 4; [0100]: At step 430, API management system 104 implements node-testing model 422. For example, API management system may route real-time API calls to node-testing model 422 in real-time to process API),
wherein the communication comprises data from the first microservice for the second microservice, the data structured in a first schema having a first set of data fields with corresponding field attributes, the first schema being different from a second schema used by the second microservice ([0101]-[0105]: FIG. 5 depicts exemplary system 500 for training a translation model… [0103]: For example, during model training translation model 502 may receive an input, which may include an API call, a dataset, an API response, a model output from another node-testing model, or other input data, such as metadata, identifiers, instructions, a source IP address, a destination IP address, or other additional data);
dynamically translating, using the one or more machine learning models and during the same runtime as training the one or more machine learning models of the schema mapper, the data in the first schema to generate translated data restructured in the second schema having second set of data fields with corresponding field attributes (Figs. 5-6; [0102]-[0105]; Translation model 502 may be trained to generate translated inputs from inputs… Translation model 502 may then determine a new translated input based on the new model output B and/or the input and model output A; [0110]: At step 608, API management system 104 translates the call);
generating a modified communication by including the translated data restructured in the second schema (Fig. 6; [0110]: Translating the call may include identifying an API version associated with the received call and implementing a translation model to generate a translated call associated with another API version); and
transmitting the modified communication to the second microservice (Fig. 6; [0111]: At step 610, API management system 104 transmits the call to a node-testing model, consistent with disclosed embodiments. In some embodiments, transmitting the call at step 610 includes transmitting the generated call of step 604 and/or the translated call of step 608).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the teaching of Layton to incorporate the teachings of Walters to include receiving a communication from the first microservice intended for the second microservice, dynamically translating the data in the first schema to generate translated data restructured in the second schema, generating a modified communication by including the translated data restructured in the second schema, and transmitting the modified communication to the second microservice.
The motivation for doing so would be to improve API translation, as recognized by Walters ([0006] of Walters: The disclosed embodiments provide unconventional methods and systems for managing models by testing and implementing API models to improve problems with API management, such as API translation).
Regarding Claim 2, the combined teachings of Layton and Walters disclose the method of claim 1.
Layton further teaches wherein using the one or more machine learning models comprises using a naive Bayes model ([0136]: Examples of machine learning techniques can include, but are not limited to… naïve Bayes classifiers).
Regarding Claim 3, the combined teachings of Layton and Walters disclose the method of claim 1.
Walters further teaches wherein the one or more machine learning models are associated with a probability distribution tensor ([0072]: For example, the data-profiling model may include algorithms to determine… a probability distribution function… or any other descriptive metric of a dataset).
Regarding Claim 4, the combined teachings of Layton and Walters disclose the method of claim 3.
Walters further teaches wherein the probability distribution tensor comprises probabilities, determined at a plurality of points in a network hosting the first microservice and the second microservice, of corresponding key-value pairs to map one or more fields between the first schema and the second schema ([0072]: The data-profiling model may include algorithms to determine a data type, key-value pairs, row-column data structure, statistical distributions of information such as keys or values, or other property of a data schema; [0099]: The model-result category may indicate a confidence level associated with the model result (e.g., a likelihood that the model result matches API output). The confidence level may include one or more probability vectors associated with particular model outputs based on the model input).
Regarding Claim 8, the combined teachings of Layton and Walters disclose the method of claim 1.
Layton further teaches wherein the one or more machine learning models are trained using an unsupervised approach (Fig. 16; [0223]: The machine learning system 1608 may train models using supervised, semi-supervised, and/or unsupervised training techniques).
Regarding Claim 9, the combined teachings of Layton and Walters disclose the method of claim 1.
Layton further teaches further comprising: in response to transmitting the modified communication, receiving an error message from the second microservice that the translated data is not compatible with the second microservice ([0383]-[0384]: A training error determination module 5214 may determine an error value 5218 for the two entities (A,B)); and
in response to receiving the error message, retraining the one or more machine learning models using a supervised approach ([0383]: The machine learning process 5210 may use the feedback 5218 to train the artificial intelligence system 5212 to produce the duplicate likelihood value 5220 that approximates the corresponding duplicate entity indication value 5216 (e.g., minimizes the error value 5218)).
Regarding Claim 11, Layton discloses a system comprising: at least one processor; and a computer readable non-transitory storage medium storing computer program instructions that when executed by the at least one processor cause the at least one processor to perform operations comprising (Fig. 14; [0185]: The processing system 300 includes one or more processors that execute computer-readable instructions and non-transitory memory that stores the computer-readable instructions):
listening, using a shared application fabric plugin, to a plurality of communications between a first microservice and a second microservice (Fig. 16; [0215]-[0218]: the ticket management system 1604 may listen for requests to generate a new ticket (e.g., an API call requesting a new ticket)… In embodiments, the conversation system 1606 is implemented as a set of microservices that can power a chat bot);
training, during a runtime, one or more machine learning models using the plurality of communications to generate a schema mapper (Fig. 16; [0219]-[0228]: The conversation system 1606 may utilize machine learned models (e.g., neural networks) that are trained on service-related conversations to process text received from a contact and extract a meaning from the text; [0007]: the customization system may include an object schema service for providing an object definition application programming interface (API) for receiving the custom object information from the user device), the training comprising:
detecting a text that is categorized to a first data field in a first subset communication data records of the plurality of communications and categorized to second data field in a second subset of communication data records of the plurality of communications ([0229]: FIG. 17A illustrates an example schema of a contact database record 1700… The contact identifier (“ID”) 1702 may be a unique value (e.g., string or number) that uniquely identifies the contact from other contacts… the client ID 1704 defines the relationship between the contact and the client);;
compositing, using the detected text, the first data field, and the second data field, a plurality of schemas used by the plurality of communications to generate one or more of a one-to-many mapping between a first generalized class to multiple specific instances or a one-to- one mapping between a second generalized class and a corresponding specific instance (Fig. 16; [0228]: In embodiments, the proprietary database(s) 1620 may store and index data records… FIGS. 17A-17C illustrate example high level schemas of contact records 1700 (FIG. 17A), client records 1720 (FIG. 17B), and ticket records 1740 (FIG. 17C); [0101]: The data-profiling model may include algorithms to determine a data type, key-value pairs, row-column data structure, statistical distributions of information such as keys or values, or other property of a data schema).
However, Layton does not explicitly teach “receiving a communication from the first microservice intended for the second microservice, wherein the communication comprises data from the first microservice for the second microservice, the data structured in a first schema having a first set of data fields with corresponding field attributes, the first schema being different from a second schema used by the second microservice; dynamically translating, using the one or more machine learning models and during the same runtime as training the one or more machine learning models of the schema mapper, the data in the first schema to generate translated data restructured in the second schema having second set of data fields with corresponding field attributes; generating a modified communication by including the translated data restructured in the second schema; and transmitting the modified communication to the second microservice”.
On the other hand, in the same field of endeavor, Walters teaches
receiving a communication from the first microservice intended for the second microservice (Fig. 4; [0100]: At step 430, API management system 104 implements node-testing model 422. For example, API management system may route real-time API calls to node-testing model 422 in real-time to process API),
wherein the communication comprises data from the first microservice for the second microservice, the data structured in a first schema having a first set of data fields with corresponding field attributes, the first schema being different from a second schema used by the second microservice ([0101]-[0105]: FIG. 5 depicts exemplary system 500 for training a translation model… [0103]: For example, during model training translation model 502 may receive an input, which may include an API call, a dataset, an API response, a model output from another node-testing model, or other input data, such as metadata, identifiers, instructions, a source IP address, a destination IP address, or other additional data);
dynamically translating, using the one or more machine learning models and during the same runtime as training the one or more machine learning models of the schema mapper, the data in the first schema to generate translated data restructured in the second schema having second set of data fields with corresponding field attributes (Figs. 5-6; [0102]-[0105]; Translation model 502 may be trained to generate translated inputs from inputs… Translation model 502 may then determine a new translated input based on the new model output B and/or the input and model output A; [0110]: At step 608, API management system 104 translates the call);
generating a modified communication by including the translated data restructured in the second schema (Fig. 6; [0110]: Translating the call may include identifying an API version associated with the received call and implementing a translation model to generate a translated call associated with another API version); and
transmitting the modified communication to the second microservice (Fig. 6; [0111]: At step 610, API management system 104 transmits the call to a node-testing model, consistent with disclosed embodiments. In some embodiments, transmitting the call at step 610 includes transmitting the generated call of step 604 and/or the translated call of step 608).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the teaching of Layton to incorporate the teachings of Walters to include receiving a communication from the first microservice intended for the second microservice, dynamically translating the data in the first schema to generate translated data restructured in the second schema, generating a modified communication by including the translated data restructured in the second schema, and transmitting the modified communication to the second microservice.
The motivation for doing so would be to improve API translation, as recognized by Walters ([0006] of Walters: The disclosed embodiments provide unconventional methods and systems for managing models by testing and implementing API models to improve problems with API management, such as API translation).
Regarding Claim 12, the combined teachings of Layton and Walters disclose the system of claim 11.
Layton further teaches wherein using the one or more machine learning models comprises using a naive Bayes model ([0136]: Examples of machine learning techniques can include, but are not limited to… naïve Bayes classifiers).
Regarding Claim 13, the combined teachings of Layton and Walters disclose the system of claim 11.
Walters further teaches wherein the one or more machine learning models are associated with a probability distribution tensor ([0072]: For example, the data-profiling model may include algorithms to determine… a probability distribution function… or any other descriptive metric of a dataset).
Regarding Claim 14, the combined teachings of Layton and Walters disclose the system of claim 13.
Walters further teaches wherein the probability distribution tensor comprises probabilities, determined at a plurality of points in a network hosting the first microservice and the second microservice, of corresponding key-value pairs to map one or more fields between the first schema and the second schema ([0072]: The data-profiling model may include algorithms to determine a data type, key-value pairs, row-column data structure, statistical distributions of information such as keys or values, or other property of a data schema; [0099]: The model-result category may indicate a confidence level associated with the model result (e.g., a likelihood that the model result matches API output). The confidence level may include one or more probability vectors associated with particular model outputs based on the model input).
Regarding Claim 18, Layton discloses a computer readable non-transitory storage medium storing computer program instructions that when executed cause operations comprising (Fig. 14; [0185]: The processing system 300 includes one or more processors that execute computer-readable instructions and non-transitory memory that stores the computer-readable instructions):
listening, using a shared application fabric plugin, to a plurality of communications between a first microservice and a second microservice (Fig. 16; [0215]-[0218]: the ticket management system 1604 may listen for requests to generate a new ticket (e.g., an API call requesting a new ticket)… In embodiments, the conversation system 1606 is implemented as a set of microservices that can power a chat bot);
training, during a runtime, one or more machine learning models using the plurality of communications to generate a schema mapper (Fig. 16; [0219]-[0228]: The conversation system 1606 may utilize machine learned models (e.g., neural networks) that are trained on service-related conversations to process text received from a contact and extract a meaning from the text; [0007]: the customization system may include an object schema service for providing an object definition application programming interface (API) for receiving the custom object information from the user device), the training comprising:
detecting a text that is categorized to a first data field in a first subset communication data records of the plurality of communications and categorized to second data field in a second subset of communication data records of the plurality of communications ([0229]: FIG. 17A illustrates an example schema of a contact database record 1700… The contact identifier (“ID”) 1702 may be a unique value (e.g., string or number) that uniquely identifies the contact from other contacts… the client ID 1704 defines the relationship between the contact and the client);;
compositing, using the detected text, the first data field, and the second data field, a plurality of schemas used by the plurality of communications to generate one or more of a one-to-many mapping between a first generalized class to multiple specific instances or a one-to- one mapping between a second generalized class and a corresponding specific instance (Fig. 16; [0228]: In embodiments, the proprietary database(s) 1620 may store and index data records… FIGS. 17A-17C illustrate example high level schemas of contact records 1700 (FIG. 17A), client records 1720 (FIG. 17B), and ticket records 1740 (FIG. 17C); [0101]: The data-profiling model may include algorithms to determine a data type, key-value pairs, row-column data structure, statistical distributions of information such as keys or values, or other property of a data schema).
However, Layton does not explicitly teach “receiving a communication from the first microservice intended for the second microservice, wherein the communication comprises data from the first microservice for the second microservice, the data structured in a first schema having a first set of data fields with corresponding field attributes, the first schema being different from a second schema used by the second microservice; dynamically translating, using the one or more machine learning models and during the same runtime as training the one or more machine learning models of the schema mapper, the data in the first schema to generate translated data restructured in the second schema having second set of data fields with corresponding field attributes; generating a modified communication by including the translated data restructured in the second schema; and transmitting the modified communication to the second microservice”.
On the other hand, in the same field of endeavor, Walters teaches
receiving a communication from the first microservice intended for the second microservice (Fig. 4; [0100]: At step 430, API management system 104 implements node-testing model 422. For example, API management system may route real-time API calls to node-testing model 422 in real-time to process API),
wherein the communication comprises data from the first microservice for the second microservice, the data structured in a first schema having a first set of data fields with corresponding field attributes, the first schema being different from a second schema used by the second microservice ([0101]-[0105]: FIG. 5 depicts exemplary system 500 for training a translation model… [0103]: For example, during model training translation model 502 may receive an input, which may include an API call, a dataset, an API response, a model output from another node-testing model, or other input data, such as metadata, identifiers, instructions, a source IP address, a destination IP address, or other additional data);
dynamically translating, using the one or more machine learning models and during the same runtime as training the one or more machine learning models of the schema mapper, the data in the first schema to generate translated data restructured in the second schema having second set of data fields with corresponding field attributes (Figs. 5-6; [0102]-[0105]; Translation model 502 may be trained to generate translated inputs from inputs… Translation model 502 may then determine a new translated input based on the new model output B and/or the input and model output A; [0110]: At step 608, API management system 104 translates the call);
generating a modified communication by including the translated data restructured in the second schema (Fig. 6; [0110]: Translating the call may include identifying an API version associated with the received call and implementing a translation model to generate a translated call associated with another API version); and
transmitting the modified communication to the second microservice (Fig. 6; [0111]: At step 610, API management system 104 transmits the call to a node-testing model, consistent with disclosed embodiments. In some embodiments, transmitting the call at step 610 includes transmitting the generated call of step 604 and/or the translated call of step 608).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the teaching of Layton to incorporate the teachings of Walters to include receiving a communication from the first microservice intended for the second microservice, dynamically translating the data in the first schema to generate translated data restructured in the second schema, generating a modified communication by including the translated data restructured in the second schema, and transmitting the modified communication to the second microservice.
The motivation for doing so would be to improve API translation, as recognized by Walters ([0006] of Walters: The disclosed embodiments provide unconventional methods and systems for managing models by testing and implementing API models to improve problems with API management, such as API translation).
Regarding Claim 19, the combined teachings of Layton and Walters disclose the non-transitory storage medium of claim 18.
Layton further teaches wherein using the one or more machine learning models comprises using a naive Bayes model ([0136]: Examples of machine learning techniques can include, but are not limited to… naïve Bayes classifiers).
Regarding Claim 20, the combined teachings of Layton and Walters disclose the non-transitory storage medium of claim 18.
Walters further teaches wherein the one or more machine learning models are associated with a probability distribution tensor ([0072]: For example, the data-profiling model may include algorithms to determine… a probability distribution function… or any other descriptive metric of a dataset).
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to SHIRLEY D. HICKS whose telephone number is (571)272-3304. The examiner can normally be reached Mon - Fri 7:30 - 4:00.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Charles Rones can be reached on (571) 272-4085. 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.
/S.D.H./Examiner, Art Unit 2168
/CHARLES RONES/Supervisory Patent Examiner, Art Unit 2168
Prosecution Insights