Notice of Pre-AIA or AIA Status
1. The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Specification
2. The disclosure is objected to because it contains an embedded hyperlink and/or other form of browser-executable code. See, e.g., [0003], [0040], and [0104] of Applicants’ specification.
Applicants are required to delete the embedded hyperlink and/or other form of browser-executable code; references to websites should be limited to the top-level domain name without any prefix such as http:// or other browser-executable code. See MPEP § 608.01.
Claim Rejections - 35 USC § 102
3. 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.
4. The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office Action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
5. Claims 1, 3-4, 13-15, and 29 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by U.S. Patent Application Publication No. 2018/0232663 (“Ross”).
Regarding claim 1, ROSS teaches A computer-implemented method (the computer discussed in relation to FIG. 11 (and starting at [0108]) is understood to be an example of the server of FIG. 1, as equipped with processor and memory elements ([0109]) to constitute software / executable instructions ([0108]-[0110]) to implement the invention taught by Ross) performed by a network node (FIG. 1’s element 100: a server) in a communication network (per FIG. 1, the network permitting communication among the at least elements 195, 100, 140, 150, 160, and 170), the method comprising:
receiving, from a data provider entity ([0063] discussing the server’s receipt of a user’s request from a user device, such as user devices 150/170 as shown in FIG. 1, where these user devices are equivalent to the recited “data provider entity”), a request for retrieving or executing a machine learning model or a combination of a plurality of machine learning models (the user device providing a request specifying criteria per FIG. 8 step 800, the request is effectively one to acquire a machine learning model as evidenced via the server’s response per step 830), the request including a first description of at least one specified output feature and a specified input data type and distribution of input values for the machine learning model or the combination of a plurality of machine learning models (per FIG. 8 step 800, as discussed per [0063], the request specifies criteria (“description” as recited) inclusive of “a label describing a feature to identify in an input data” (i.e., specifying both the input data and the output data for the target model being requested), and where the input data can be of many types/formats or combinations thereof (per [0035], [0085]) and even can be of numerous instances such that the inputs are multiple inputs (i.e., a distribution for inputs would be implicit in a number of inputs) ([0035] and [0085], but also [0074] (in processing the request, “ the server can provide various input data”)));
obtaining, from a repository containing a plurality of machine learning models (in handling the request of FIG. 8 step 800, the server obtains ML models, e.g., from FIG. 1 element 195 (equivalent to the recited “repository”)) each having a second description of at least one specified output feature and input data type (where the models are understood to be described/characterized in terms of their inputs and outputs ([0006], [0030]), an identification of at least one machine learning model or at least one combination of a plurality of machine learning models having a second description that at least partially satisfies a match to the first description ([0031] and [0067]-[0068] discussing the obtaining of models by the server and identification of models that have a description/characterization in terms of input/output that match that of the user’s request);
identifying at least one candidate machine learning model from the plurality of machine learning models based on (1) a first comparison of the second description of each of the plurality of machine learning models to the first description to obtain a first identity of any subset of the plurality of machine learning models having a second description that matches the first description, and (2) a second comparison of the second description to each of the remaining of the plurality of machine learning models, other than the subset, to obtain a second identity of at least one machine learning model that, or one at least one combination of machine learning models from the remaining machine learning models that when combined, produce the at least one specified output of the first description ([0031] and [0067]-[0068] discussing the obtaining of models by the server and identification of models that have a description/characterization in terms of input/output that match that of the user’s request, and where the identified model does not meet the accuracy threshold for the comparison, then the model is combined with other models to create a resulting model that does); and
selecting a third description of the identified at least one candidate machine learning model based on a convergence of the first identity and the second identity (the resulting combined model, as noted above, is equivalent to a convergence of two models such that the resulting combined model is then selected for satisfaction of the user’s request).
Regarding claim 3, Ross teaches the method of claim 1, wherein the first description comprises a plurality of specified input data types, the distribution of input values for the plurality of specified input data types, and at least one output feature having the specified input data type (per FIG. 8 step 800, as discussed per [0063], the request specifies criteria (“description” as recited) inclusive of “a label describing a feature to identify in an input data” (i.e., specifying both the input data and the output data for the target model being requested), and where the input data can be of many types/formats or combinations thereof (per [0035], [0085]) and even can be of numerous instances such that the inputs are multiple inputs (i.e., a distribution for inputs would be implicit in a number of inputs) ([0035] and [0085], but also [0074] (in processing the request, “ the server can provide various input data”))).
Regarding claim 4, Ross teaches the method of claim 3, wherein the distribution of input values comprises a name of the distribution and at least one parameter for the distribution (per FIG. 8 step 800, as discussed per [0063], the request specifies criteria (“description” as recited) inclusive of “a label describing a feature to identify in an input data” (i.e., specifying both the input data and the output data for the target model being requested), and where a label per [0059] may be a hierarchical label such that it can encompass a collection/distribution of labels and where the high level hierarchical label may be understood to be a “name of the distribution” as recited, and may also be specified with a correlation per [0060] which contextualizes or clarifies the distribution/input based on the label (i.e., “at least one parameter for the distribution” as recited)).
Regarding claim 13, Ross teaches the method of claim 1, wherein the network node is located at one of: physically co-located with at least one of the data processing entity and the repository; physically located separate from at least one of the data processing entity and the repository; a core network node of a mobile network; a local-private cloud; and a public cloud (in clarification of FIG. 1, [0033]: “The server 100 can be part of a cloud. The server 100 communicates with various other computing devices such as user devices, other servers, and/or databases over a communication network 140. The communication network 140 can be any communication network, such as the Internet, a cellular data network, a local area network, a mesh network, etc. The communication network 140 can be wired or wireless.”, where the Examiner reasons that a wired network as taught reads on a network with “physically co-located” elements as recited, and a cloud-based server as taught reads on private/public cloud variations as recited, and a wireless network as taught reads on “physically located separate from” arrangement of elements as recited, and a mesh network or a cellular data network as taught reads on “mobile network” arrangements as recited).
Regarding claim 14, Ross teaches the method of claim 1, wherein the data processing entity is located at one of: physically co-located with at least one of the network node and the repository; physically located separate from at least one of the network node and the repository; a cell site in a mobile network; and a router (in clarification of FIG. 1, [0033]: “The server 100 can be part of a cloud. The server 100 communicates with various other computing devices such as user devices, other servers, and/or databases over a communication network 140. The communication network 140 can be any communication network, such as the Internet, a cellular data network, a local area network, a mesh network, etc. The communication network 140 can be wired or wireless.” as discussed just above in relation to claim 13, where the Examiner reasons that the user device per FIG. 1 can be arranged in a network that is “wired” or “wireless” as taught and thereby reading on network arrangements that are respectively “physically co-located” or “physically located separate from” as both recited, and that a network that is a cellular or mesh network as taught reads on network arrangements that are akin to a “mobile network” as recited).
Regarding claim 15, the claim includes the same or similar limitations as claim 1 discussed above, and is therefore rejected under the same rationale. The claim specifically recites elements for at least one processor and at least one memory which are taught per [0109]-[0114] (in relation to FIG. 1’s server, for example).
Regarding claim 29, ROSS teaches A data processing entity ([0063] discussing the server’s receipt of a user’s request from a user device, such as user devices 150/170 as shown in FIG. 1, where these user devices are equivalent to the recited “data processing entity”) in a communication network (per FIG. 1, the network permitting communication among the at least elements 195, 100, 140, 150, 160, and 170), the data processing entity comprising:
at least one processor (a user device as shown in FIG. 1 is understood to by the Examiner to be any general-purpose computer that is capable of making a request to a server in a network as shown in FIG. 1 and as noted in [0063], and in view of that would be understood by one of ordinary skill in the art to include a processor as recited);
at least one memory (a user device as shown in FIG. 1 is understood to by the Examiner to be any general-purpose computer that is capable of making a request to a server in a network as shown in FIG. 1 and as noted in [0063], and in view of that would be understood by one of ordinary skill in the art to include a memory element as recited) connected to the at least one processor and storing program code that is executed by the at least one processor to perform operations comprising:
send, to a network node (FIG. 1’s element 100: a server), a request for retrieving or executing a machine learning model or a combination of a plurality of machine learning models (the user device providing a request specifying criteria per FIG. 8 step 800, the request is effectively one to acquire a machine learning model as evidenced via the server’s response per step 830), the request including a first description of at least one specified output feature and a specified input data type and distribution of input values for the machine learning model or the combination of a plurality of machine learning models (per FIG. 8 step 800, as discussed per [0063], the request specifies criteria (“description” as recited) inclusive of “a label describing a feature to identify in an input data” (i.e., specifying both the input data and the output data for the target model being requested), and where the input data can be of many types/formats or combinations thereof (per [0035], [0085]) and even can be of numerous instances such that the inputs are multiple inputs (i.e., a distribution for inputs would be implicit in a number of inputs) ([0035] and [0085], but also [0074] (in processing the request, “ the server can provide various input data”))).
Claim Rejections - 35 USC § 103
6. 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.
7. 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.
8. Claims 2, 10-11, and 30 are rejected under 35 U.S.C. 103 as being unpatentable over Ross in view of Non-Patent Literature “Knowledge Elicitation Tool Classification” (“Burge”).
Regarding claim 2, Ross teaches the method of claim 1, as discussed above. As discussed, Ross teaches receiving a set of the specified input data from the data provider entity ([0063] discussing the server’s receipt of a user’s request from a user device, such as user devices 150/170 as shown in FIG. 1, where these user devices are equivalent to the recited “data provider entity”) and verifying the identified at least one candidate machine learning model against the ... set of the specified input data from the data provider entity ([0068] discussing the server’s verification of accuracy of the different retrieved models in their processing of the user request’s specified criteria/information), but Ross does not teach that it’s a full set specifically as further recited and that the full set is further received subject to the server’s requesting [of] a full set of the specified input data from the data provider entity. Rather, the Examiner relies upon BURGE to teach what Ross otherwise lacks, see e.g., Burge’s knowledge elicitation as generally discussed at the top of page 3 (under the heading Knowledge Elicitation Methods), where this is understood by the Examiner to suggest obtaining information as determined necessary to do the task at hand, and is amenable to be computer-implemented per page 9’s discussion of a Simulation type elicitation method. As incorporated into a framework such as Ross’s, where a user specifies a number of inputs, the Examiner reasons that if further inputs are necessary to evaluate the user’s request, then elicitation per Burge provides at least the suggestion that the necessary information could be requested.
Both Ross and Burge relate to modeling/simulation frameworks as discussed above, and to the extent that inputs are processed to provide some output, both are similarly directed and therefore analogous. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate Burge’s elicitation into Ross’s client-server communication, and specifically Ross’s request and request handling features, with a reasonable expectation of success, such that Ross’s server is better equipped to obtain all the information necessary from the client/user to perform the request processing task at hand.
Regarding claim 10, Ross in view of Burge teaches the method of claim 2, as discussed above. The aforementioned references teach the additional limitations wherein the request further comprises metadata, and wherein the verifying comprises use of symbolic expression to match context from the metadata with metadata of the identified at least one candidate machine learning model (Ross’s FIG. 8, as discussed beginning at [0063], mentions the user’s request as specifying labels ([0063]), such that the labels of the request are compared against the labels of the models to be considered ([0067]), and where the labels as discussed are essentially metadata in relation to both the user’s request and the models as characterized/described and the basis of their consideration and selection, and moreover a label could be understood to be a symbol). The motivation for combining the references is as discussed above in relation to claim 2.
Regarding claim 11, Ross in view of Burge teaches the method of claim 10, as discussed above. The aforementioned references teach the additional limitations wherein the context comprises a symbolic representation (Ross’s labels as discussed in relation to its FIG. 8 are equivalent to a symbol). The motivation for combining the references is as discussed above in relation to claim 2.
Regarding claim 30, the claim essentially includes the same or similar limitations as discussed above in relation to claims 1 and 2 as considered together, and is therefore similarly rejected under Ross in view of Burge.
9. Claims 6 and 12 are rejected under 35 U.S.C. 103 as being unpatentable over Ross in view of U.S. Patent Application Publication No. 2019/0156247 (“Faulhaber”).
Regarding claim 6, Ross teaches the method of claim 1, as discussed above. The aforementioned reference does not teach the additional limitations wherein the identification in the obtaining comprises an identifier for the identified at least one candidate machine learning model, inputs to the identified at least one candidate machine learning model, and an output feature of the identified at least one candidate machine learning model. At best, Ross teaches that a user interface ([0040]-[0041]) for the user device is used to realize the delivery of the model from the server to the user device in satisfaction of the user’s request. That said, Ross does not specifically teach doing so via something akin to “an identifier” as recited. Rather, the Examiner relies upon FAULHABER to teach what Ross otherwise lacks, see e.g., Faulhaber’s [0068] teaching a visual feedback to users in a comparable model framework that processes inference requests and that also involves comparable model selection and model evaluation features to those contemplated by Ross, where the feedback per [0068] is described with a granularity that permits per-model comprehension/detail by the user.
Both Ross and Faulhaber relate to model selection and evaluation frameworks as arranged in a client-server configuration. Hence, they are similarly directed and therefore analogous. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate Faulhaber’s more detailed model-granular feedback into Ross’s framework, with a reasonable expectation of success, for purposes of providing more interpretability to the end user and even any administrator of the framework such that the functionality of the framework could be better understood and monitored.
Regarding claim 12, Ross teaches the method of claim 1, as discussed above. The aforementioned reference do not teach the additional limitations further comprising: sending the selected third description of the identified at least one candidate machine learning model to the data processing entity. At best, Ross teaches that a user interface ([0040]-[0041]) for the user device is used to realize the delivery of the model from the server to the user device in satisfaction of the user’s request. That said, Ross does not specifically teach doing so via something akin to “an identifier” as recited. Rather, the Examiner relies upon FAULHABER to teach what Ross otherwise lacks, see e.g., Faulhaber’s [0068] teaching a visual feedback to users in a comparable model framework that processes inference requests and that also involves comparable model selection and model evaluation features to those contemplated by Ross, where the feedback per [0068] is described with a granularity that permits per-model comprehension/detail by the user.
Both Ross and Faulhaber relate to model selection and evaluation frameworks as arranged in a client-server configuration. Hence, they are similarly directed and therefore analogous. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate Faulhaber’s more detailed model-granular feedback into Ross’s framework, with a reasonable expectation of success, for purposes of providing more interpretability to the end user and even any administrator of the framework such that the functionality of the framework could be better understood and monitored.
10. Claim 5 is rejected under 35 U.S.C. 103 as being unpatentable over Ross in view of Non-Patent Literature “Generative Adversarial Networks” (“Goodfellow”).
Regarding claim 5, Ross teaches the method of claim 3, as discussed above. The aforementioned reference does not teach the additional limitations wherein the input distribution is an unknown distribution, and the input distribution is characterized using moments. Rather, the Examiner relies upon GOODFELLOW to teach what Ross otherwise lacks, see e.g., Goodfellow’s page 139, 2nd column, 3rd paragraph under section 2: “Another approach to unsupervised learning is generative modeling. In generative modeling, training examples x are drawn from an unknown distribution pdata (x). The goal of a generative modeling algorithm is to learn a pmodel (x) that approximates pdata (x) as closely as possible.”, where the training examples are akin to the recited moments and the input distribution is explicitly unknown.
Ross contemplates a framework with a model store/repository that is subject to consideration and use in satisfying inference requests. Goodfellow teaches a type of model that could be stored in such a model store/repository and be subject to inference. Hence, the references are similarly directed and therefore analogous. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate a model as taught by Goodfellow into the model store/repository as taught by Ross (e.g., as mapped to in relation to claim 1).
11. Claim 37 is rejected under 35 U.S.C. 103 as being unpatentable over Ross in view of U.S. Patent Application Publication No. 2017/0177696 (“Biesemann”).
Regarding claim 37, Ross teaches the data processing entity of claim 29, as discussed above. The aforementioned reference Ross teaches the additional limitations wherein the operations further comprise to: responsive to the request, receive from the network node the identified at least one candidate machine learning model or a description of the identified at least one candidate machine learning model (Ross: the user device providing a request specifying criteria per FIG. 8 step 800, the request is effectively one to acquire a machine learning model as evidenced via the server’s response per step 830). Ross teaches model validation/verification, but at the server (Ross: [0068] discussing the server’s verification of accuracy of the different retrieved models in their processing of the user request’s specified criteria/information), and hence then does not teach doing so at the client/user device per the further limitation to verify the identified at least one candidate machine learning model. Rather, the Examiner relies upon BIESEMANN to teach what Ross otherwise lacks, see e.g., Beisemann’s FIG. 3 step 308 to teach that a request may be validated at the client device instead of at the server in a similarly-arranged client-server framework.
Ross contemplates a client-server framework used to satisfy model inference requests from the user/client. Beisemann as discussed above is analogously arranged. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to validate/verify the request on the client/user side as Beisemann teaches as incorporated into Ross’s framework, with a reasonable expectation of success, such that either network element can feasibly provide the same function as a matter of design and advantage.
12. Claim 38 is rejected under 35 U.S.C. 103 as being unpatentable over Ross in view of Non-Patent Literature “Understanding Neural Networks with Layerwise Relevance Propagation and Deep Taylor Series” (“Shiebler”).
Regarding claim 38, Ross teaches the data processing entity of claim 29, as discussed above. Ross does not teach the further limitations wherein the operation to verify comprises to:
obtain an output of analysis from a model interpretation method to check whether the specified input data type and distribution of input values carry an importance over the output feature, and whether the importance is propagated through different layers of the identified at least one combination of machine learning models, and when the importance is propagated, approve the identified at least one combination of machine learning models.
Rather, the Examiner relies upon SHIEBLER to teach what Ross otherwise lacks, see e.g., Shiebler’s framework for understanding models with a layerwise relevance propagation (page 2’s 1st paragraph, page 4’s discussion of decomposing network output into the sum of relevances of input values such that (page 5) relevance of each neuron in the input can be known).
Both Ross and Shiebler relate to model evaluation in some respects, and hence are similarly directed and therefore analogous. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate Shiebler’s analysis into Ross’s framework, with a reasonable expectation of success, for purposes of providing more interpretability to the end user and even any administrator of the framework such that the functionality of the framework could be better understood and monitored.
13. Claim 9 is rejected under 35 U.S.C. 103 as being unpatentable over Ross in view of Burge and further in view of Shiebler.
Regarding claim 9, Ross in view of Burge teaches the method of claim 2, as discussed above. Ross does not teach the further limitations wherein the verifying comprises, for the identified at least one candidate machine learning model, obtaining an output of analysis from a model interpretation method to check whether the input features carry an importance over the output feature, and whether the importance is propagated through different layers of the identified at least one candidate machine learning models, and when the importance is propagated, approval of the identified at least one candidate machine learning model. Rather, the Examiner relies upon SHIEBLER to teach what Ross otherwise lacks, see e.g., Shiebler’s framework for understanding models with a layerwise relevance propagation (page 2’s 1st paragraph, page 4’s discussion of decomposing network output into the sum of relevances of input values such that (page 5) relevance of each neuron in the input can be known).
Both Ross and Shiebler relate to model evaluation in some respects, and hence are similarly directed and therefore analogous. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate Shiebler’s analysis into Ross’s framework, with a reasonable expectation of success, for purposes of providing more interpretability to the end user and even any administrator of the framework such that the functionality of the framework could be better understood and monitored.
14. Claims 7-8 are rejected under 35 U.S.C. 103 as being unpatentable over Ross in view of Burge and further in view of U.S. Patent No. 11763154 (“Lupesko”) and U.S. Patent No. 7480640 (“Elad”).
Regarding claim 7, Ross in view of Burge teaches the method of claim 2, as discussed above. The aforementioned references further teach the additional limitations wherein the verifying comprises use of a partial or the full set of the specified input data as a test set of data for an evaluation of accuracy of the identified at least one candidate machine learning model (Ross: [0031] and [0067]-[0068] discussing the obtaining of models by the server and identification of models that have a description/characterization in terms of input/output that match that of the user’s request, and where the identified model does not meet the accuracy threshold for the comparison, then the model is combined with other models to create a resulting model that does) but do not teach the further limitations wherein the specified input data comprises an input vector and wherein the test set of data comprises a set of tuples of the input features and the corresponding output features. Rather, the Examiner relies upon LUPESKO and ELAD to teach what Ross etc. otherwise lack, see e.g. the following:
LUPESKO’s column 4 lines 31-44 discussing a modeling request, comparable to Ross’s inference request, where the input is explicitly a vector.
ELAD’s modeling framework, as clarified at column 1 lines 28-51, involves a tuple to explicitly manage the organization of inputs with outputs.
Like Ross, Lupesko and Elad relate to machine learning modeling and platforms that facilitate their use by way of requests and the like. Hence, the references are similarly directed and therefore analogous. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to use data structures known and used in the state of the art, such as a vector and a tuple as taught by Lupesko an Elad as noted above, to manage the information in a framework such as Ross’s, with a reasonable expectation of success, specifically to manage similar data with similar data structures via an approach that is apparently known/practiced.
Regarding claim 8, Ross in view of Burge and further in view of Lupesko and Elad teaches the method of claim 7, as discussed above. The aforementioned references further teach the additional limitations subsequent to the verifying, further comprising:
choosing the identified at least one candidate machine learning model based on the greatest accuracy or on training the identified at least one candidate machine learning model with a subset of the full set of the specified input data (Ross: [0031] and [0067]-[0068] discussing the obtaining of models by the server and identification of models that have a description/characterization in terms of input/output that match that of the user’s request, and where the identified model does not meet the accuracy threshold for the comparison, then the model is combined with other models to create a resulting model that does); and
sending the identified at least one candidate machine learning model, or a token for execution of the identified at least one candidate machine learning model, to the data processing entity (Ross: the resulting combined model, as noted above, is equivalent to a convergence of two models such that the resulting combined model is then selected for satisfaction of the user’s request).
The motivation for combining the references is as discussed above in relation to claim 7.
Conclusion
15. The prior art made of record and not relied upon is considered pertinent to Applicants’ disclosure:
US-11847545-B2
US-20200334020-A1
US-20210357745-A1
Non-Patent Literature “A Gentle Introduction to Model Selection for Machine Learning”
Non-Patent Literature “A Multi-model Combination Approach for Probabilistic Wind Power Forecasting”
Non-Patent Literature “Preprocess input data before making predictions using Amazon SageMaker AI inference pipelines and Scikit-learn”
Non-Patent Literature “Using Amazon SageMaker inference pipelines with multi-model endpoints”
Non-Patent Literature “Generative Moment Matching Networks”
Non-Patent Literature “MMDGAN: Towards Deeper Understanding of Moment Matching Network”
16. Any inquiry concerning this communication or earlier communications from the examiner should be directed to SHOURJO DASGUPTA whose telephone number is (571)272-7207. The examiner can normally be reached M-F 8am-5pm CST.
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, Tamara Kyle can be reached at 571 272 4241. 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.
/SHOURJO DASGUPTA/Primary Examiner, Art Unit 2144
