DETAILED ACTION
Claims 1, 8, and 16 are amended. Claims 1-20 are pending in the application.
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 .
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.
Examiner’s Notes
The Examiner cites particular sections in the references as applied to the claims below for the convenience of the applicant(s). Although the specified citations are representative of the teachings in the art and are applied to the specific limitations within the individual claim, other passages and figures may apply as well. It is respectfully requested that, in preparing responses, the applicant(s) fully consider the references in their entirety as potentially teaching all or part of the claimed invention, as well as the context of the passage as taught by the prior art or disclosed by the Examiner.
Response to Amendment
Amendments to claims 1, 8, and 16 are fully considered and are satisfactory to overcome the rejections under 35 U.S.C. §101 directed claims 1-20 in the previous Office Action.
Claim Objections
Claims 1-7 are objected to because of the following informalities:
Claim 1: “in memory” (line 4) should have been –in the memory—.
Claims 2-7 inherit the features of claim 1 and are objected to accordingly.
Appropriate corrections are required. Applicant is advised to review the entire claims for further needed corrections.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
Claims 1-6 and 8-20 are rejected under 35 U.S.C. 103 as being unpatentable over Mora López et al. (US 2018/0113857 A1; hereinafter Mora López) in view of Olcese et al. (US 2018/0183880 A1; hereinafter Olcese).
With respect to claim 1, Mora López teaches: A system (see e.g. Mora López, Fig. 4) comprising:
memory (see e.g. Mora López, Fig. 4: “Memory 994”);
a processing system (see e.g. Mora López, Fig. 4: “Processor 993”);
stored in memory (see e.g. Mora López, paragraph 136: “software library 12 of FIG. 1, and the storing a plurality of software services step S201 of FIG. 2, may be a processor 993 (or plurality thereof) executing processing instructions (a program) stored on a memory 994”) that:
receives, from an application (see e.g. Mora López, Fig. 1: “User Interface 11”; and paragraph 75: “a web interface; an application programming interface; a command line interface; a user voice command interface; and a graphical user interface”), inputs (see e.g. Mora López, paragraph 8: “receive a plurality of user input commands”; paragraph 75: “user interface 11 interacts with the user to enable user input commands to be input to the apparatus 10. The user interface 11 comprises at least one means for interacting with a user. For example, the user interface includes at least one of: a web interface; an application programming interface; a command line interface; a user voice command interface; and a graphical user interface”; and Fig. 2, step S202) including a semantic description (see e.g. Mora López, paragraph 19: “semantic descriptors”) of a requested function capability (see e.g. Mora López, paragraph 8: “receive a plurality of user input commands, each user input command expressed in a domain specific language and defining a data processing target and a data processing request”; and paragraph 19: “data processing request elements are, for example, semantic descriptors of data processing functions”);
interprets a parameter specified within the inputs or within a configuration file for the application (see e.g. Mora López, paragraph 8: “parser is configured to extract from each user input command: the data processing request from the domain specific language; and the defined data processing target”; paragraph 77: “extracting parameters from user commands”; and Fig. 2, step S203) to determine an execution constraint (see e.g. Mora López, paragraph 78: “data processing request from the domain specific language; and the defined data processing target”) associated with the requested function capability (see e.g. Mora López, paragraph 77: “A step of extracting from each user input command: the data processing request from the domain specific language; and the defined data processing target…the term parameters is used as shorthand for the extracted data processing request & data processing target”; and paragraph 78: “parser 13 is configured to extract information from the user input that can be used to control execution of software services. Noting that the software services each perform a single data processing function on input data, the information required to extract is a requested data processing function (or functions) and a location from which the input data for processing is accessible. In particular, the parser 13 is configured to extract from each user input command: the data processing request from the domain specific language; and the defined data processing target”);
queries a function registry (see e.g. Mora López, paragraph 33: “maintain a software service registry, the software service registry comprising an entry for each of the plurality of software services, the entry identifying the respective software service and specifying a data processing function performed by the software service when executed”; paragraph 96: “a registry of software services with an entry per software service”) based at least in part on the requested function capability (see e.g. Mora López, paragraph 84: “parsed data processing request defines one or more data processing functions… extracted (i.e. made explicit) by the software service execution scheduler 14, for example, by reference to the software services themselves or to a registry of software services maintained by the service execution scheduler 14”), the function registry defining each of a plurality of functions (see e.g. Mora López, paragraph 84: “a registry entry indicating that it performs a summarize data processing function… a registry entry indicating that it performs a load data processing function… a registry entry indicating that it performs a table join”; and paragraph 96: “a registry of software services with an entry per software service, the entry identifying the software service and defining the data processing function performed by the software service when executed”) in association with a semantic description of a function capability (see e.g. Mora López, paragraph 84: “the parsed data processing request may be “summarize””; and paragraph 96: “Said definition may be in terms of a semantic descriptor of the data processing function… data processing function is defined semantically in the registry (for example, “tokenize”; “load”; “summarize”; “compare”) and one or more execution characteristics (see e.g. Mora López, paragraph 84: “a registry entry indicating that it performs a summarize data processing function. However, the registry entry specifies that input data is to be stored locally as a single table. Another software service has a registry entry indicating that it performs a load data processing function, with input data being an external database and a data processing result being a locally stored table of data. Another software service has a registry entry indicating that it performs a table join on locally stored tables, taking plural locally stored tables as inputs and generating as a processing result a single locally stored table”; and paragraph 85: “the data processing request may be defined in terms of a processing result… a registry of software services of the software library 12, defined in terms of the input data on which they are operable, and the output generated (for example, both input and output defined by a data type or semantic descriptor thereof”);
identifies, based on information returned from the function registry, a set of candidate functions (see e.g. Mora López, paragraph 84: “determine the constituent data processing function(s)”) that are each defined in the function registry (see e.g. Mora López, paragraph 84: “parsed data processing request is performed by the software service execution scheduler 14 in order to determine the constituent data processing function(s)… extracted (i.e. made explicit) by the software service execution scheduler 14, for example, by reference to the software services themselves or to a registry of software services”) in association with a corresponding semantic description of a function capability matching the requested function capability (see e.g. Mora López, paragraph 84: “parsed data processing request may be “summarize” and the data processing target may be plural disparate relational databases”; paragraph 96: “A match between a data processing function specified for a software service in the registry and a data processing function forming part of a data processing request (an instructed data processing function) is an indication that the software service for which the processing function is specified is suitable to perform the instructed data processing function. The match is based on the definition of the instructed data processing function, and the data processing function specified for the software service in the registry. The match may be based on semantics”);
selects, from the set of candidate functions, a select function that is defined in the function registry (see e.g. Mora López, paragraph 85: “software service execution controller 14, upon identifying a type of data of the parsed data processing target, then compiles a schedule by selecting software services in a stepwise fashion to go from the type of data of the parsed data processing target to the type of data of the processing result of the data processing request”; paragraph 88: “A schedule, which may also be referred to as an execution schedule or execution plan, is a plan identifying which software services to execute”; and Fig. 2, step S205) in association with a set of execution characteristics satisfying the execution constraint (see e.g. Mora López, paragraph 85: “selecting software services in a stepwise fashion to go from the type of data of the parsed data processing target to the type of data of the processing result of the data processing request”; paragraph 88: “identifying which software services to execute, in which order (noting that the order may include parallel execution of plural software services), and with which input data… compilation of an element of the execution schedule may be dependent upon the outcome of execution of preceding software services in the execution schedule”; and paragraph 89: “schedule is compiled by the software service execution scheduler 14 in order to fulfill the parsed data processing request… determining a software service or series of software services stored by the software library 12 which, when executed (in the case of a series, with proceeding software services in the series taking as an input the processing result(s) of one or more preceding software service(s) in the series) transform the data processing target output by the parser 13 into the particular data type sought as a processing result and specified by the parsed data processing request”; and paragraph 95: “A match between a data processing function specified for a software service in the registry and a data processing function forming part of a data processing request (an instructed data processing function) is an indication that the software service for which the processing function is specified is suitable to perform the instructed data processing function. The match is based on the definition of the instructed data processing function, and the data processing function specified for the software service in the registry. The match may be based on semantics… additionally, the definition of the instructed data processing function may be defined in terms of input data and requested processing result, for example, defining each by a semantic descriptor of the data type (“tabular data” “matrix” “document” “vector”) or by a filename extension. The data processing functions specified in the registry may be defined in the same way, so that a match is matching input and output filename extensions, or matching (i.e. semantic similarity above a threshold) input and output semantic data type descriptors”);
executes the select function (see e.g. Mora López, paragraph 18: “data processing function performed by the software service when executed”; paragraph 37: “controlling execution of the compiled schedule of one or more software services, the defined data processing target being the input data to the controlled execution”; paragraph 91: “A step of controlling execution of the compiled schedule of one or more software services, the defined data processing target being the input data to the controlled execution; is represented by step S206 in FIG. 2”; and Fig. 2, step S206); and
returns an output of the select function (see e.g. Mora López, paragraph 20: “output the obtained processing result to the user via the user interface”; and paragraph 37: “outputting a processing result of said controlled execution”; paragraph 91: “A step of outputting a processing result of the controlled execution is represented by S207 in FIG. 2”; and Fig. 2, step S207).
Even though Mora López discloses instructions stored in the memory 994 to implement the above steps (see e.g. Mora López, paragraph 136), Mora López does not explicitly disclose these instructions forming a “capability proxy”.
However, Olcese teaches:
a capability proxy (see e.g. Olcese, Fig. 1: “Capability Proxy 128”; and paragraph 29: “capability proxy 128 may be configured to receive (e.g., via a stateless protocol message, such as a REST call) request data that identifies a particular hardware resource 134 and an application (e.g., the application 122 or the application 146) that has requested to pair with the particular hardware resource 134. In response to receipt of the request data, the capability proxy 128 may be configured to provide (e.g., via a stateless protocol message, such as a REST call), an approval of the pairing request or a denial of the pairing request”)
Mora López and Olcese are analogous art because they are in the same field of endeavor: managing data processing requests. Therefore, it would have been obvious to one with ordinary skill in the art before the effective filing date of the claimed invention to modify Mora López with the teachings of Olcese. The motivation/suggestion would be to improve security associated with the data processing requests (see e.g. Olcese, paragraph 29).
With respect to claim 2, Mora López as modified teaches: The system of claim 1, wherein the function registry includes, for each function of a plurality of functions:
a semantic description of function capability (see e.g. Mora López, paragraph 19: “data processing request elements are, for example, semantic descriptors of data processing functions. The software service registry entries may be generated by a system administrator of the apparatus upon addition of software services to the software library”; and paragraph 35: “records may be stored with a characterization of the data processing target (i.e. …semantic representation of concept instantiated by the data”); and
a corresponding execution characteristic (see e.g. Mora López, paragraph 22: “records of data processing requests and defined data processing targets on which the identification of the data processing request candidate is based are constrained to records of data processing requests and defined data processing targets input to the user interface”; and paragraph 35: “software service execution scheduler makes a selection from among plural candidates based on maintained records of selections made by a user. Such records may be stored with a characterization of the data processing target (i.e. values of one or more characteristics of the data: data size; data type; semantic representation of concept instantiated by the data) for processing by the software services from which the selection was made”).
With respect to claim 3, Mora López as modified teaches: The system of claim 1, wherein the function registry further includes an application programming interface (API) syntax usable to invoke each function included in the function registry (see e.g. Mora López, paragraph 56: “an API can be written in accordance with the REST guiding principles for interfaces to the software services, and would hence be described as a ‘RESTful API’. Such a restful API for a software service may be stored in a registry entry for a software service”), and
Mora López does not but Olcese teaches:
wherein the capability proxy constructs a call to the select function using the API syntax that is specified in the function registry in association with the select function (see e.g. Olcese, paragraph 29: “capability proxy 128 may be configured to receive (e.g., via a stateless protocol message, such as a REST call), a request for access to a particular hardware resource 134 from an application (e.g., the application 122 or the application 146), and to evaluate a pairing token provided with the access request. If the capability proxy 128 validates the pairing token, the capability proxy 128 may be configured to provide (e.g., via a stateless protocol message, such as a REST call) data from the hardware resource 134 for provision to the application (thereby granting access to the hardware resource”).
Mora López and Olcese are analogous art because they are in the same field of endeavor: managing data processing requests utilizing APIs (e.g. REST API). Therefore, it would have been obvious to one with ordinary skill in the art before the effective filing date of the claimed invention to modify Mora López with the teachings of Olcese. The motivation/suggestion would be to improve security associated with the data processing requests (see e.g. Olcese, paragraph 29).
With respect to claim 4, Mora López as modified teaches: The system of claim 1, wherein the function registry further includes capability acquisition information identifying an endpoint (see e.g. Mora López, paragraph 73: “URI or URL”; and paragraph 92) that provides the select function as a service (see e.g. Mora López, paragraph 73: “each user input command at least partially expressed in a domain specific language and defining a data processing target and a data processing request. The data processing target may be defined by a URI or URL at which the data processing target (i.e. some data such as a file) is accessible”; and paragraph 92: “ input data to the first of a series of software services in the schedule is the data processing target defined in the user input, with the input data of subsequent software services in the schedule being the processing result of the adjacent preceding software service in the schedule. Input data may be specified by reference to a URI or URL from which it is accessible”) and wherein the capability proxy queries the endpoint of when executing the select function (see e.g. Mora López, paragraph 73: “data processing target may be defined by a URI or URL at which the data processing target (i.e. some data such as a file) is accessible”; and paragraph 92: “ input data to the first of a series of software services in the schedule is the data processing target defined in the user input, with the input data of subsequent software services in the schedule being the processing result of the adjacent preceding software service in the schedule. Input data may be specified by reference to a URI or URL from which it is accessible”).
With respect to claim 5, Mora López as modified teaches: The system of claim 1, wherein the execution constraint specifies at least one of function execution cost, function result accuracy (see e.g. Mora López, paragraph 111: “software services perform data processing functions for data science and data analysis. Information output by the data processing apparatus 10 in response to questions posed by the user, such as in line 3, is tailored to provide information useful to a data science professional. For example in line 4 the user interface outputs to the user accurate information that could be used for support purposes”), function latency, function power consumption, or function service provider type.
With respect to claim 6, Mora López as modified teaches: The system of claim 1, wherein the execution constraint is included in the semantic description (see e.g. Mora López, paragraph 8: “receive a plurality of user input commands, each user input command expressed in a domain specific language and defining a data processing target and a data processing request”; paragraph 19: “data processing request elements are, for example, semantic descriptors of data processing functions”; and paragraph 22: “records of data processing requests and defined data processing targets on which the identification of the data processing request candidate is based are constrained to records of data processing requests and defined data processing targets input to the user interface”).
With respect to claims 8-13: Claims 8-13 are directed to a method corresponding to the active functions implemented by the system recited in claims 1-6, respectively; please see the rejection directed to claims 1-6 above which also cover the limitations recited in claims 8-13.
With respect to claim 14, Mora López as modified teaches: The method of claim 8,
Mora López does not but Olcese teaches:
wherein the capability proxy includes an enterprise-configurable setting that identifies the execution constraint (see e.g. Olcese, paragraph 3: “Access to these hardware resources is conventionally controlled by proprietary protocols or is manually configured as part of an enterprise device group”; and paragraph 29: “capability proxy 128 may be configured to receive (e.g., via a stateless protocol message, such as a REST call) request data that identifies a particular hardware resource 134 and an application (e.g., the application 122 or the application 146) that has requested to pair with the particular hardware resource 134).
Mora López and Olcese are analogous art because they are in the same field of endeavor: managing data processing requests. Therefore, it would have been obvious to one with ordinary skill in the art before the effective filing date of the claimed invention to modify Mora López with the teachings of Olcese. The motivation/suggestion would be to improve security associated with the data processing requests (see e.g. Olcese, paragraph 29).
With respect to claim 15, Mora López as modified teaches: The method of claim 8,
Mora López does not but Olcese teaches:
wherein the capability proxy is offered as a web-hosted service (see e.g. Olcese, paragraph 31: “application 122 may communicate with the networking API 130, which may in turn communicate with the capability proxy 128 via a device-to-device pathway. One example of a device-to-device pathway that may be used is a Web Real-Time Communication (WebRTC) pathway… Communication between the traffic server 120 and the capability proxy 138 may take place via a cloud pathway or cloud device-to-device pathway, such as an Extensible Messaging and Presence Protocol (XMPP) pathway”; and Fig. 1).
Mora López and Olcese are analogous art because they are in the same field of endeavor: managing data processing requests. Therefore, it would have been obvious to one with ordinary skill in the art before the effective filing date of the claimed invention to modify Mora López with the teachings of Olcese. The motivation/suggestion would be to improve security associated with the data processing requests (see e.g. Olcese, paragraph 29).
With respect to claims 16 and 17: Claims 16 and 17 are directed to a tangible computer-readable storage media encoding computer-executable instructions for executing a computer process corresponding to the active functions implemented by the system recited in claims 1 and 4; please see the rejection directed to claims 1 and 4 above which also cover the limitations recited in claims 16 and 17. Note that, Mora López also discloses a computer-readable medium storing computer-executable instructions for executing a computer process corresponding to the active functions implemented by the system recited in claims 1 and 4 (see e.g. Mora López, paragraph 132).
With respect to claim 18, Mora López as modified teaches: The tangible computer-readable storage media of claim 16, wherein the capability acquisition information indicates a tool usable to generate code to invoke a service (see e.g. Mora López, paragraph 56: “an interface developed in accordance with these principles can be described as ‘RESTful’. For example, an API can be written in accordance with the REST guiding principles for interfaces to the software services, and would hence be described as a ‘RESTful API”) and wherein executing the select function further includes using the tool to generate the code to invoke the service (see e.g. Mora López, paragraph 55: “software services, whether microservices or otherwise, may be RESTful software services, each defining methods for GET, and POST and/or PUT requests”; and paragraph 56: “an API can be written in accordance with the REST guiding principles for interfaces to the software services, and would hence be described as a ‘RESTful API’. Such a restful API for a software service may be stored in a registry entry for a software service stored by the software service execution scheduler 14, or stored in a location made accessible (for example, by a reference) by a reference in said registry”).
With respect to claim 19: Claim 19 is directed to a tangible computer-readable storage media encoding computer-executable instructions for executing a computer process corresponding to the active functions implemented by the system recited in claims 2 and 3; please see the rejections directed to claims 2 and 3 above which also cover the limitations recited in claim 19.
With respect to claim 20, Mora López as modified teaches: The tangible computer-readable storage media of claim 16, wherein the execution constraint is included in at least one of the semantic description received from the application (see e.g. Mora López, paragraph 8: “receive a plurality of user input commands, each user input command expressed in a domain specific language and defining a data processing target and a data processing request”; paragraph 19: “data processing request elements are, for example, semantic descriptors of data processing functions”) or a configuration file of the application.
Claim 7 is rejected under 35 U.S.C. 103 as being unpatentable over Mora López in view of Olcese as applied to claim 1 above, and further in view of Malamut et al. (US 9,424,112 B1; hereinafter Malamut).
With respect to claim 7, Mora López as modified teaches: The system of claim 1,
Mora López does not but Malamut teaches:
wherein the capability proxy determines the execution constraint based on a configuration file of an application (see e.g. Malamut, column 6, lines 8-12: “The inputs to the EPB are: (1) a dependency configuration file (DCF), which describes the mapping of data items, resultant data (goals) to be persisted, what data is to be persisted and how the device authentication is to be performed” and lines 45-47: “The DCF provides information regarding how to access an API, the application goals to be retrieved via the API and data transformations”).
Mora López and Malamut are analogous art because they are in the same field of endeavor: managing data processing schedules/plans. Therefore, it would have been obvious to one with ordinary skill in the art before the effective filing date of the claimed invention to modify Mora López with the teachings of Malamut. The motivation/suggestion would be to improve the scheduling process (see e.g. Malamut, column 1, lines 16-62).
Response to Arguments
Applicant's arguments filed 12/08/2025 have been fully considered but they are not persuasive. In detail:
(i) Regarding claim 1, Applicant argues that Mora López fails to disclose the limitations “selects, from the set of candidate functions, a select function that is defined in the function registry in association with a set of execution characteristics satisfying the execution constraint” are recited (see Remarks, pages 16-17).
However, note that Mora López discloses compiling an execution schedule comprising functions selected from a set of constituent functions defined in a registry in association with function types, function inputs, and function outputs (i.e. execution characteristics of the functions) which are matched to user-provided data processing request and corresponding data processing target (i.e. user-provided execution constraints).
More specifically, Mora López discloses a software service execution scheduler 14 that maintains a registry of software services that identify corresponding data processing functions and data processing targets (i.e. function inputs/outputs) (see e.g. Mora López, paragraph 84: “a registry of software services maintained by the service execution scheduler 14”), such as a registry entry identifying a “summarize” data processing function taking a locally stored single table as input, a registry entry identifying a “load” data processing function taking an external database as input and returning a locally stored data table as output, or a registry entry identifying a “table join” function taking locally stored tables as inputs and generating a single locally stored table as an output, etc. (see e.g. Mora López, paragraph 84).
In view of a user’s command (see e.g. Mora López, Fig. 2, step S202), the scheduler 14 semantically determines constituent data processing functions (i.e. a set of candidate functions) from the registry corresponding to the data processing request identified with the user’s command (see e.g. Mora López, paragraph 84: “parsed data processing request is performed by the software service execution scheduler 14 in order to determine the constituent data processing function(s)… extracted (i.e. made explicit) by the software service execution scheduler 14, for example, by reference to the software services themselves or to a registry of software services”)
The scheduler 14 then compiles an execution schedule of software services by selecting software services matching the data processing request and data processing target identified with the user’s command (see e.g. Mora López, paragraph 85: “selecting software services in a stepwise fashion to go from the type of data of the parsed data processing target to the type of data of the processing result of the data processing request”; paragraph 88: “identifying which software services to execute, in which order (noting that the order may include parallel execution of plural software services), and with which input data… compilation of an element of the execution schedule may be dependent upon the outcome of execution of preceding software services in the execution schedule”; paragraph 89: “schedule is compiled by the software service execution scheduler 14 in order to fulfill the parsed data processing request… determining a software service or series of software services stored by the software library 12 which, when executed (in the case of a series, with proceeding software services in the series taking as an input the processing result(s) of one or more preceding software service(s) in the series) transform the data processing target output by the parser 13 into the particular data type sought as a processing result and specified by the parsed data processing request”; and paragraph 95: “A match between a data processing function specified for a software service in the registry and a data processing function forming part of a data processing request (an instructed data processing function) is an indication that the software service for which the processing function is specified is suitable to perform the instructed data processing function”).
That is, the scheduler 14 selects functions that are defined in the registry in association with input/output characteristics satisfying the execution constraints defined by the user’s command.
Therefore, Mora López teaches the limitations “selects, from the set of candidate functions, a select function that is defined in the function registry in association with a set of execution characteristics satisfying the execution constraint” as recited in claim 1, and the similar limitations recited in claims 8 and 16. For more details, please see the rejections directed to claims 1, 8, and 16 above.
CONCLUSION
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure:
Sazegari et al. (US 2010/0125836 A1) discloses utilizing a semantical analyzer to identify and select executable functions based on accuracy criteria (see paragraphs 62, 80, 81).
THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Contact Information
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Umut Onat whose telephone number is (571)270-1735. The examiner can normally be reached M-Th 9:00-7:30.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Kevin L Young can be reached at (571) 270-3180. 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.
/UMUT ONAT/Primary Examiner, Art Unit 2194