DETAILED ACTION
This communication is response to the application filed 08/23/24. Claims 1-28 are pending and presented for examination.
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 .
Priority
Receipt is acknowledged of certified copies of papers required by 37 CFR 1.55.
Information Disclosure Statement
The information disclosure statement (IDS) submitted on 12/31/2024 and 05/12/2025 is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Regarding claims 1, 7, 20, and 26, the claim limitations merely discloses generating a first message and sending the first message, wherein the message solely indicates “information” about any “network environment change” of a second node that executes any task. It is unclear what the roles of the “nodes” are, or which technical significance the “environment” holds in the claim, or in general, what the whole technical purpose of the claim is. The claim language fails to disclose the technical subject-matter for which protection is sought. Thus, the claim language is unclear and thus renders the claim indefinite.
Claim Rejections - 35 USC § 102
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.
Claim(s) 1, 2, 7, 8, 20, 22, 26 and 28 is/are rejected under 35 U.S.C. 102(a)(1) as being anticipated by US 2018/0150339 to Pan et al. (hereafter Pan).
Regarding claim 1, Pan discloses a first node (see Pan, Fig 1 and Fig 5) comprising:
a processor, the processor being configured to execute a computer program (see Pan, ¶ 0039: the coordinator 114 can include a processor and memory collectively configured to manage communications between any combination of coordinated devices 112, client devices 102, and devices of the service provider network 120) thereby causing the first node to:
generate a first message, wherein the first message is useable to indicate information about a network environment change of a second node (see Pan, ¶ 0039: the coordinator 114 may enable a client device 102 to transmit a request to change the state of a coordinated device 112, and cause such a change in state to occur. As a further example, the coordinator 114 may enable a user to specify a criterion under which a state of a coordinated device 112 should be changed, and then automatically operate to change the state of the coordinated device 112 when the criterion is satisfied; ¶ 0040: the service provider environment 150 may collect, for an established environment 110 with one or more coordinated devices 112, data identifying a content or format of transmission of such devices 112 and the tasks utilized to manage operation of such devices 112. Thereafter, newly created coordinated environments 110 may be monitored for identical or similar transmissions, and the tasks utilize in the established environment 110 may be presented for potential use in the newly create environment 110; ¶ 0090), the second node being configured to execute a first task (see Pan, ¶ 0039: The coordinator can further be configured to enable executions of tasks, in a manner similar to an on-demand code execution environment 120 of the service provider environment 120. These tasks may implement a variety of user-defined or non-user-defined functionalities, including communicating with coordinated devices 112, client devices 102, and devices of the service provider network 120; ¶ 0056: Tasks executed by the coordinator 114 are shown as logically grouped within the tasks memory space 280, which may correspond to a logical unit of memory 250 configured to store the code corresponding to each task; ¶ 0125); and ;
send the first message to a third node (see Pan, ¶ 0023: The coordinator may notify the coordinated device via the communication protocol of the change in state of the device shadow, and the coordinated device may respond by synchronizing a local state to the state of the device shadow. Use of device shadows may be advantageous, for example, in decoupling requests to read or modify the state of a coordinated device from communications with the coordinated device; ¶ 0077: the device shadow service 130 notifies the coordinator 114 of a change to the device shadow for the coordinator 114. In one embodiment, the notification may occur via the MQTT protocol, as a notification that a message has been published to a topic associated with coordinator (wherein the message may represent the updated device shadow, and the topic may correspond to the device shadow); ¶ 0039: the coordinator 114 may enable a client device 102 to transmit a request to change the state of a coordinated device 112, and cause such a change in state to occur).
Regarding claim 3, Pan discloses the first node according to claim 1, wherein the first message is useable to further indicate indicates at least one of: identification information of the first task, a priority of the first task, or a probability of the network environment change of the second node (see Pan, ¶ 0102: a scheduling algorithm may also be based at least in part on a priority assigned to the task by an author of the task, by an administrator of the coordinator, by a calling entity, etc.; ¶ 0136: the call may further include other information, such as parameters to pass to the task prior to or during execution, or parameters for controlling how the task executes (e.g., a priority of the task)).
Regarding claim 7, Pan discloses a third node (see Pan, Fig 1 and Fig 5) comprising:
a processor, the processor being configured to execute a computer program (see Pan, ¶ 0039: the coordinator 114 can include a processor and memory collectively configured to manage communications between any combination of coordinated devices 112, client devices 102, and devices of the service provider network 120) thereby causing the first node to:
receive a first message from a first node, wherein the first message is useable to indicate information about a network environment change of a second node (see Pan, ¶ 0039: the coordinator 114 may enable a client device 102 to transmit a request to change the state of a coordinated device 112, and cause such a change in state to occur. As a further example, the coordinator 114 may enable a user to specify a criterion under which a state of a coordinated device 112 should be changed, and then automatically operate to change the state of the coordinated device 112 when the criterion is satisfied; ¶ 0040: the service provider environment 150 may collect, for an established environment 110 with one or more coordinated devices 112, data identifying a content or format of transmission of such devices 112 and the tasks utilized to manage operation of such devices 112. Thereafter, newly created coordinated environments 110 may be monitored for identical or similar transmissions, and the tasks utilize in the established environment 110 may be presented for potential use in the newly create environment 110; ¶ 0090), and the second node is configured to execute a first task (see Pan, ¶ 0039: The coordinator can further be configured to enable executions of tasks, in a manner similar to an on-demand code execution environment 120 of the service provider environment 120. These tasks may implement a variety of user-defined or non-user-defined functionalities, including communicating with coordinated devices 112, client devices 102, and devices of the service provider network 120; ¶ 0056: Tasks executed by the coordinator 114 are shown as logically grouped within the tasks memory space 280, which may correspond to a logical unit of memory 250 configured to store the code corresponding to each task; ¶ 0125); and
update configuration information of the first task based on the first message (see Pan, ¶ 0024: a coordinator may be associated with a user, who may alter the configuration of the coordinator via an environment of a service provider; ¶ 0058: Because different communication manager tasks 286 can vary the ability of the coordinator 114 to communicate via different protocols, and because the tasks of the coordinator 114 may be altered via reconfiguration of the coordinator 114, the coordinator 114 can be rapidly reconfigured to utilize a variety of different communication protocols; ¶ 0080: the coordinator 114 retrieves the tasks referenced within the configuration package from the on-demand code execution environment 150. Illustratively, the coordinator 114 may utilizes identifiers of each task to request that code corresponding to the task, and any other information (such as metadata) regarding the task, be transmitted to the coordinator 114; ¶ 0081: the coordinator 114 updates itself with the newly obtained configuration. Illustratively, the coordinator 114 may update a set of configuration data, such as a list of coordinated devices 112, within its memory. The coordinator 114 may further replace a current set of tasks with newly obtained tasks, as referenced in the new configuration information).
Regarding claim 8, Pan discloses the third node according to claim 7, wherein the first message is useable to further indicate at least one of: identification information of the first task, a priority of the first task, or a probability of the network environment change of the second node (see Pan, ¶ 0102: a scheduling algorithm may also be based at least in part on a priority assigned to the task by an author of the task, by an administrator of the coordinator, by a calling entity, etc.; ¶ 0136: the call may further include other information, such as parameters to pass to the task prior to or during execution, or parameters for controlling how the task executes (e.g., a priority of the task)).
Regarding claim 20, it is rejected for the same reasons as set forth in claim 1. Although phrased as a method claim, the claim is nevertheless simple repetitions of the subject matter of claim 1.
Regarding claim 22, it is rejected for the same reasons as set forth in claim 3. Although phrased as a method claim, the claim is nevertheless simple repetitions of the subject matter of claim 3.
Regarding claim 26, it is rejected for the same reasons as set forth in claim 1. Although phrased as a non-transitory computer-readable storage medium claim, the claim is nevertheless simple repetitions of the subject matter of claim 1.
Regarding claim 28, it is rejected for the same reasons as set forth in claim 3. Although phrased as a non-transitory computer-readable storage medium claim, the claim is nevertheless simple repetitions of the subject matter of claim 3.
Claim(s) 1-3, 7, 8, 10, 11, 17-22, and 26-28 is/are rejected under 35 U.S.C. 102(a)(1) as being anticipated by WO 2021/030818 to FUTUREWEI TECHNOLOGIES INC (hereafter Futurewei), see IDS dated.
Regarding claim 1, Futurewei discloses a first node comprising:
a processor, the processor being configured to execute a computer program thereby causing the first node to: generate a first message, wherein the first message is useable to indicate information about a network environment change of a second node, the second node being configured to execute a first task; and send the first message to a third node (see Futurewei, Fig 3-16; page 2 line 22-page 3 line 32, Summary: partitioning, by MEC distributed controller, the execution of the service into a plurality of tasks, with each task being executable on a MEC node; and selecting, by the MEC distributed controller, for each task in the plurality of tasks, a subset of the pool of MEC nodes in accordance with a selection function…. Generating, by the MEC distributed controller, for each MEC nodes of the pool of MEC nodes; and selecting, by the MEC distributed controller, for each task of the plurality of tasks, a MEC node from the pool of MEC nodes for executing the task, the selecting being in accordance with the cost and the value for executing the task on the MEC node, thereby producing the subset of the pool of MEC nodes…..determining, the MEC distributed controller, an updated executing plan and an updated pool of MEC nodes in accordance with the updated geo-location information; scheduling, by the MEC distributed controller, the updated execution plan over the updated pool of MEC nodes to produce an updated scheduled execution plan; and deploying, by the MEC distributed controller, the updated scheduled execution plan; page 17 line 10-page 18 line 4: MEC system choreography function 611 accepts service task request, verifies policy, performs planning (e.g., resource planning, priority planning, geo-location based planning, etc.), schedules tasks and jobs, and distributed the jobs, MEC system choreography 611 includes a planning function 639, a policy management function 641, and a scheduling function 643. Planning function639 performs resource planning, priority planning, geo-location based planning, etc. Planning function 639 also accepts task requests (as received from a mobile device, for example). Planning function 639 further shares information regarding resource status (such as a computational resources status), number of computational resources available, number of computational resources idle, percentage of computational resources available, percentage of computational resources idle, and so on. In other words, planning function 639 performs high-level planning of resources, priority, etc., based on geo-location information, and partitions the service based on computational resource availability. Should a change occur to some of the geo-location information (e.g.., the route of the mobile device changes, etc.) that impacts the MEC sites and MEC nodes making up the virtual resource pool, planning function 639 may need to repeat the high-level planning for the service to reflect the changed geo-location information. Policy management function 641 verifies policy, such as QoS policy matching, security matching, and so on. Scheduling function 643 schedules the tasks and jobs associated with the service (as partitioned by planning function 639) and distributes the jobs to the MEC nodes. The jobs may be assigned to MEC nodes with policy restrictions, priority requirements, output deadlines, etc. In other words, scheduling function 643 performs low-level scheduling of tasks and jobs associated with the service to MEC nodes and MEC sites. Typically, scheduling function 643 dynamically schedules the tasks and jobs associated with the service based on changes in the geo-location information (e.g., the mobile device encounters a traffic jam and has to slow down, an accident causes a delay in the progress of the mobile device, and so on) that does not change the route of the mobile device but changes the location of the mobile device along the route as a function of time; page 19 lines 9-17: the MEC distributed controller is decentralized, with each MEC site having a MEC distributed controller implementation. As an example, each MEC site features a MEC system choreography function with a decentralized planning function, decentralized policy management function, and a decentralized scheduling function. In an embodiment, although each of the MEC sites includes a decentralized MEC distributed controller, collaboration is performed between the MEC distributed controllers. Collaboration between the MEC distributed controllers may include the sharing of planning information, policy information, scheduling information, priority information, task times and deadlines, geo-location information, and so forth).
Regarding claim 2, Futurewei discloses the first node according to claim 1, wherein the processor is further configured to execute the computer program thereby further causing the first node to: determine a probability of the network environment change of the second node occurs occurring is greater than or equal to a preset threshold (see Futurewei, page 15 lines 7-13).
Regarding claim 3, Futurewei discloses the first node according to claim 1, wherein the first message is useable to further indicate at least one of: identification information of the first task, a priority of the first task, or a probability of the network environment change of the second node (see Futurewei, page 17 lines 10-27; page 24 lines 3-18).
Regarding claim 7, Futurewei discloses a third node comprising: a processor, the processor being configured to execute a computer program thereby causing the first node to: receive a first message from a first node, wherein the first message is useable to indicate information about a network environment change of a second node, and the second node is configured to execute a first task; and update configuration information of the first task based on the first message (see Futurewei, page 16 lines 9-31: Figure 6 illustrates a high-level view of a MEC site 600. The high-level view of MEC site 600 presents a view of the software framework 609 and a MEC distributed controller 603. The MEC distributed controller 603 includes a MEC infrastructure layer 605, a MEC hosting infrastructure 607, and a MEC system choreography function 611, MEC distributed controller 603 includes components used in controlling the operation of MEC site 600, as well as planning, scheduling, and distributing layers of offloaded services executing on resources of MEC site 600. In an embodiment, MEC distributed controller 603 performs planning, scheduling, and distributing of layers of offloaded services executing on resources of MEC 600, as well as resources of other MEC sites in close proximity to MEC site 600. MEC infrastructure layer 605 includes information related to the configuration of MEC site 600, including control plane information 615 for the configuration of the control plane MEC site 600, data plane information 617 for the configuration of the data plane of MEC site 600, and mobile device or access node information 619 for the configuration of mobile devices and access nodes coupled to MEC site 600; page 17 line 10-page 18 line 4: MEC system choreography function 611 accepts service task request, verifies policy, performs planning (e.g., resource planning, priority planning, geo-location based planning, etc.), schedules tasks and jobs, and distributed the jobs, MEC system choreography 611 includes a planning function 639, a policy management function 641, and a scheduling function 643. Planning function639 performs resource planning, priority planning, geo-location based planning, etc. Planning function 639 also accepts task requests (as received from a mobile device, for example). Planning function 639 further shares information regarding resource status (such as a computational resources status), number of computational resources available, number of computational resources idle, percentage of computational resources available, percentage of computational resources idle, and so on. In other words, planning function 639 performs high-level planning of resources, priority, etc., based on geo-location information, and partitions the service based on computational resource availability. Should a change occur to some of the geo-location information (e.g.., the route of the mobile device changes, etc.) that impacts the MEC sites and MEC nodes making up the virtual resource pool, planning function 639 may need to repeat the high-level planning for the service to reflect the changed geo-location information. Policy management function 641 verifies policy, such as QoS policy matching, security matching, and so on. Scheduling function 643 schedules the tasks and jobs associated with the service (as partitioned by planning function 639) and distributes the jobs to the MEC nodes. The jobs may be assigned to MEC nodes with policy restrictions, priority requirements, output deadlines, etc. In other words, scheduling function 643 performs low-level scheduling of tasks and jobs associated with the service to MEC nodes and MEC sites. Typically, scheduling function 643 dynamically schedules the tasks and jobs associated with the service based on changes in the geo-location information (e.g., the mobile device encounters a traffic jam and has to slow down, an accident causes a delay in the progress of the mobile device, and so on) that does not change the route of the mobile device but changes the location of the mobile device along the route as a function of time; page 19 lines 9-17: the MEC distributed controller is decentralized, with each MEC site having a MEC distributed controller implementation. As an example, each MEC site features a MEC system choreography function with a decentralized planning function, decentralized policy management function, and a decentralized scheduling function. In an embodiment, although each of the MEC sites includes a decentralized MEC distributed controller, collaboration is performed between the MEC distributed controllers. Collaboration between the MEC distributed controllers may include the sharing of planning information, policy information, scheduling information, priority information, task times and deadlines, geo-location information, and so forth; Fig 3-16).
Regarding claim 8, Futurewei discloses the third node according to claim 7, wherein the first message is useable to further indicate at least one of: identification information of the first task, a priority of the first task, or a probability of the network environment change of the second node (see Futurewei, page 17 lines 10-27; page 24 lines 3-18).
Regarding claim 10, Futurewei discloses the third node according to claim 7, wherein the network environment change of the second node includes the first task executed by the second node being interrupted; and the processor is further configured to execute the computer program thereby further causing the third node to: determine a fifth node configured to execute the first task (see Futurewei, page 2 lines 22-27; page 4 lines 22-29).
Regarding claim 11, Futurewei discloses the third node according to claim 7, wherein the processor is further configured to execute the computer program thereby further causing the third node to: send updated configuration information of the first task (see Futurewei, page 28 lines 11-18).
Regarding claim 17, Futurewei discloses the third node according to claim 10, wherein the processing processor is further configured to execute the computer program thereby further causing the third node to: update to the fifth node that the second node is configured to execute the first task, and is in a task topology relationship (see Futurewei, page 28 lines 11-18).
Regarding claim 18, Futurewei discloses the third node according to claim 7, wherein the network environment change of the second node comprises one of: the second node entering the idle state; or the second node performing cell handover; or the first task executed by the second node being interrupted (see Futurewei, page 25 lines 3-14; page 30 lines 14-17).
Regarding claim 19, Futurewei discloses the third node according to claim 7, wherein the network environment change of the second node includes changing a status of the first task (see Futurewei, page 25 lines 3-14).
Regarding claim 20, it is rejected for the same reasons as set forth in claim 1. Although phrased as a method claim, the claim is nevertheless simple repetitions of the subject matter of claim 1.
Regarding claim 21, it is rejected for the same reasons as set forth in claim 2. Although phrased as a method claim, the claim is nevertheless simple repetitions of the subject matter of claim 2.
Regarding claim 22, it is rejected for the same reasons as set forth in claim 3. Although phrased as a method claim, the claim is nevertheless simple repetitions of the subject matter of claim 3.
Regarding claim 26, it is rejected for the same reasons as set forth in claim 1. Although phrased as a non-transitory computer-readable storage medium claim, the claim is nevertheless simple repetitions of the subject matter of claim 1.
Regarding claim 27, it is rejected for the same reasons as set forth in claim 3. Although phrased as a non-transitory computer-readable storage medium claim, the claim is nevertheless simple repetitions of the subject matter of claim 3.
Regarding claim 28, it is rejected for the same reasons as set forth in claim 3. Although phrased as a non-transitory computer-readable storage medium claim, the claim is nevertheless simple repetitions of the subject matter of claim 3.
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.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
Claim(s) 4 and 23 is/are rejected under 35 U.S.C. 103 as being unpatentable over Futurewei in view of US 2020/0068425 XUE et al. (hereafter Xue).
Regarding claim 4, Futurewei discloses the first node according to claim 3, but does not explicitly disclose wherein the processor is further configured to execute the computer program thereby further causing the first node to: send a second message to the second node, wherein the second message is useable to request to obtain the priority of the first task; and receive the priority of the first task from the second node.
However, Xue discloses send a second message to the second node, wherein the second message is useable to request to obtain the priority of the first task; and receive the priority of the first task from the second node (see Xue, ¶ 0040: The terminal device sends a priority request to the device initiating the first measurement task, and receives a priority response that carries the priority of the first measurement task and that is returned by the device initiating the first measurement task; ¶ 0076: after sending a measurement request for a measurement task to a terminal device, receiving, by an initiating device, a priority request sent by the terminal device; and after determining a priority of the measurement task, sending, by the initiating device to the terminal device, a priority response carrying the priority of the measurement task; ¶ 0466: send, by using the transceiver 1401, a priority request to the device initiating the second measurement task, and receive a priority response that carries the priority of the second measurement task and that is returned by the device initiating the second measurement task).
Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to implement the above teaching as taught by Xue and incorporate it into the system of Futurewei to improve system efficiency (see Xue, ¶ 0007).
Regarding claim 23, it is rejected for the same reasons as set forth in claim 4. Although phrased as a method claim, the claim is nevertheless simple repetitions of the subject matter of claim 4.
Claim(s) 6 and 25 is/are rejected under 35 U.S.C. 103 as being unpatentable over Futurewei.
Regarding claim 6, Futurewei discloses the first node according to claim 1, wherein the processor is further configured to execute the computer program thereby further causing the first node to: receive updated configuration information of the first task (see Futurewei, page 16 lines 20-31), but does not explicitly disclose wherein the updated configuration information of the first task is useable to indicate to the first node to delete context information of the first task.
However, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to indicate to the first node to delete context information of the first task based on user design preference to achieve intended use of deleting context information of task. One of ordinary skill in the art would have been motivated to delete context information of task since it is well-known in the art to perform this teaching.
Regarding claim 25, it is rejected for the same reasons as set forth in claim 6. Although phrased as a method claim, the claim is nevertheless simple repetitions of the subject matter of claim 6.
Allowable Subject Matter
Claims 5, 9, 12, 13-16, and 24 are objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
US 2020/0100122 to Liu discloses a secondary network node acquires a network state of a cell served by the secondary network node; the secondary network node updates a network configuration of the cell served by the secondary network node according to the network state of the cell served by the secondary network node; the secondary network node sends first update configuration information to a terminal, wherein the first update configuration information is used for updating the network configuration of the cell served by the secondary network node.
US 2009/0271639 to Burge et al. discloses apparatus and method for dynamically reassigning between a plurality of personal portable devices in a wireless network one or more task portions of a task that have been distributed among the personal portable devices in response to at least one of the personal portable devices having diminishing access to electric power. A reassignment may be prompted by the remaining electric power available to one of the personal portable devices diminishing to a predetermined level, and/or it may be prompted as a result of a goal of causing the remaining operating times of the personal portable devices engaged in performing the task to be as close to equal as possible. A reassignment may be prompted by the remaining electric power available to one of the personal portable devices being changed either by the coupling of that personal portable device to an external power supply or by a suspension of execution of a task routine associated with a task portion that had been assigned to that personal portable device.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to RASHEED GIDADO whose telephone number is (571)270-7645. The examiner can normally be reached Monday - Friday 8AM-5PM EST.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Ricky Ngo can be reached at 571-272-3139. 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.
/RASHEED GIDADO/ Primary Examiner, Art Unit 2464
Prosecution Insights