DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Priority
Acknowledgment is made of applicant’s claim for foreign priority under 35 U.S.C. 119 (a)-(d).
Information Disclosure Statement
The information disclosure statements (IDS) submitted on 12/16/2024, 01/28/2025, and 08/07/2025 have been 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.
Claim 15 is rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Regarding claim 15, the claim recites “a non-transitory computer program element on which are stored machine readable instructions radio node prioritization in a radio system, the machine readable instructions, when executed by a processor, causing the processor to perform the following steps: obtaining, for a set of radio nodes communicably coupled to a base station, enrichment information for a plurality of radio nodes included in the set of radio nodes”. The claim does not establish what constitutes an ”element” of a computer program, or the boundaries of the claimed element. The specification additionally fails to provide sufficient objective criteria for determining whether a particular software component, instruction set, module, routine, or entire program constitutes the claimed “computer program element”.
Thus, the phrase “a non-transitory computer program element” renders the claim vague and indefinite.
For examination purposes, the examiner has interpreted "a non-transitory computer program element" as a non-transitory computer readable medium.
Claim Rejections - 35 USC § 102
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 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.
Claims 1, 5-15 are rejected under 35 U.S.C. 102(a)(1) as being unpatentable over Ranganath (WO 2023091664 A1).
Regarding claim 1, Ranganath discloses the limitations:
“A computer implemented method of radio node prioritization in a radio system, comprising the following steps: obtaining, for a set of radio nodes communicably coupled to a base station, enrichment information for a plurality of radio nodes included in the set of radio nodes” ([0025] describes cells (nodes) as being able to be connected to a gNB (base stations). [0053], RIC functionality in O-RAN is disclosed. [0054], xApps manager 425 is an application for use on a computer that can collect E2 (enrichment) measurement data from xApps 420 or nodes in an O-RAN framework),
“obtaining, for the plurality of radio nodes included in the set of radio nodes, corresponding intended quality of service (QoS) profiles” ([0055] xApp manager can collect QoS requirements (equivalent to profiles),
“determining, using the obtained enrichment information: a first subset of radio nodes included in the set of radio nodes” ([0068] determine which nodes are “overfed” with resources / congestion, and also determine which nodes are “underfed” with resources / having low user data volumes),
“wherein each radio node in the first subset has, or is approaching, an unmet QoS state relative to the corresponding QoS policy of the radio node in the first subset, and/or a second subset of radio nodes included in the set of radio nodes wherein each radio node in the second subset has, or is approaching, an excess QoS state relative to the corresponding QoS policy of the radio node in the second subset” ([0068] determine which nodes are “overfed” with resources / congestion, and also determine which nodes are “underfed” with resources / having low user data volumes),
“wherein an excess QoS state is one in which a given radio node in the second subset can be downgraded or disabled for a duration; updating a QoS policy for the plurality of radio nodes included in the set of radio nodes based on the determined first subset of radio nodes and/or the determined second subset of radio nodes” ([0068], scale up or scale down QoS policy (resource allocation plan) for certain nodes depending on whether or not they are “overfed” or “underfed”),
“wherein the updating includes improving the corresponding QoS policy related to a first radio node in the plurality of radio nodes, and/or downgrading the corresponding QoS policy related to a second radio node in the plurality of radio nodes” ([0068], scale up or scale down QoS policy (resource allocation plan) for certain nodes depending on whether or not they are “overfed” or “underfed”),
and
“reconfiguring the base station coupled to the radio nodes included in the set of radio nodes based on the updated QoS policy; and transmitting at least one message to a radio node included in the set of radio nodes, wherein the at least one message includes a QoS notification for changing a QoS policy of the radio node included in the set of radio nodes” ([0056-0058], [0068], signal to entities that serve nodes (may be base stations) to reallocate resources to their nodes based on earlier reconfiguration determination, essentially reconfiguration of a base station. The signal may be a QoS notification as it relates to the reallocation of resources for the purposes of QoS improvements).
Regarding claim 5, Ranganath teaches the limitations:
“wherein the reconfiguring of the base station coupled to the radio nodes comprised in the set of radio nodes based on the updated QoS policy further includes: communicating, to a controller, the updated QoS policy of at least one radio node in the set of radio nodes” ([0047] any QoS requirements (policies 441) may be communicated using formal declarations to RIC 412 in the SMO to guide the near-RT RIC 414, and hence the RAN to updating QoS policies),
“receiving, at the base station at least one base station reconfiguration message generated in a core network based on the updated QoS policy” ([0053] The non-RT RIC 412 also guides the near-RT RIC 414 using Al policies 441 with possible inclusion of scope identifiers (e.g., Single Network Slice Selection Assistance Information (S- NSSAI), QoS Flow IDs, and/or the like) and statements (e.g., KPI targets, SLAs, and/or the like), acting as a reconfiguration message for a base station. The near-RT RIC 414 obtains policies 441 over an interface. Policies 441 may include QoS requirements as stated in [0047]),
“and reconfiguring the base station using the base station reconfiguration message to enforce the updated QoS policy on the radio nodes included in the set of radio nodes” ([0055-0058], QoS requirement-based resource allocation decisions within the near-RT RIC 414 may be conveyed using messages or message flows).
Regarding claim 6, Ranganath teaches the limitation:
“wherein the enrichment information is characterized by one or more of: (i) a binary flag indicating link health between a respective radio node and the base station, and/or (ii) an application status of at least one application executing on a radio node, and/or (iii) a message from an application executing on a radio node defining a required link quality” ([0056], app telemetry and traces (message that contains application data / status) running on an xApp can be utilized to predict a future resource (quality) requirements for an xApp).
Regarding claim 7, Ranganath teaches the limitation:
“wherein the QoS state is characterized by at least one of: (i) downlink guaranteed flow bit rate, and/or (ii) downlink maximum flow bit rate, and/or (iii) downlink maximum packet loss rate, uplink guaranteed flow bit rate, and/or (iv) uplink maximum flow bit rate, and/or (v) uplink maximum packet loss rate” ([0056], latency (e.g. maximum packet loss rate) or user data rates (e.g. uplink flow rates) may be defined as part of a QoS policy / requirement).
Regarding claim 8, Ranganath teaches the limitation:
“wherein at least one radio node in the set of radio nodes is included in a mobile telephone or an automated mobile robot or a vehicle” ([0093], a node may be a vehicle system. [0009] discloses that a UE may be a node).
Regarding claim 9, Ranganath teaches the limitation:
“wherein the computer implemented method is executed by a Radio Access Network Intelligent Controller (RIC) of an Open Radio Access Network (O-RAN)” ([0053-0054], the non-RT RIC 412 guides the near-RT RIC 414 to obtain updated QoS policies, in an O-RAN framework).
Regarding claim 10, Ranganath teaches the limitations:
“An apparatus, comprising: a radio interface; a processor; and a memory; wherein the processor is configured to: obtain, for a set of radio nodes communicably coupled to a base station, enrichment information for a plurality of radio nodes included in the set of radio nodes, obtain, for the plurality of radio nodes included in the set of radio nodes, corresponding intended quality of service profiles” ([0025] describes cells (nodes) as being able to be connected to a gNB (base stations). [0235], ORAN architecture may include a radio interface, which includes xApps and nodes as disclosed in [0008]. [0061], processor circuitry and memory circuitry 1752 and 1754. [0053], RIC functionality in O-RAN is disclosed. [0054], xApps manager 425 is an application for use on a computer that can collect E2 (enrichment) measurement data from xApps 420 or nodes in an O-RAN framework. [0055], xApp manager can collect QoS requirements (equivalent to profiles),
“determine, using the obtained enrichment information: a first subset of radio nodes comprised in the set of radio nodes wherein each radio node in the first subset has, or is approaching, an unmet QoS state relative to the corresponding QoS policy of the radio node in the first subset, and/or a second subset of radio nodes included in the set of radio nodes, wherein each radio node in the second subset has, or is approaching, an excess QoS state relative to the corresponding QoS policy of the radio node in the second subset” ([0068] determine which nodes are “overfed” with resources / congestion, and also determine which nodes are “underfed” with resources / having low user data volumes),
“wherein an excess QoS state is one in which a given radio node in the second subset can be downgraded or disabled for a duration, update a QoS policy for the plurality of radio nodes included in the set of radio nodes based on the determined first subset of radio nodes and/or the determined second subset of radio nodes” ([0068] determine which nodes are “overfed” with resources / congestion, and also determine which nodes are “underfed” with resources / having low user data volumes),
“wherein the updating includes improving the QoS policy related to a first radio node in the plurality of radio nodes, and/or downgrading the QoS policy related to a second radio node in the plurality of radio nodes, reconfigure the base station coupled to the radio nodes included in the set of radio nodes based on the updated QoS policy, and transmit at least one message to a radio node included in the set of radio nodes, wherein the at least one message includes a QoS notification for changing a QoS policy of the radio node included in the set of radio nodes” ([0068], scale up or scale down QoS policy (resource allocation plan) for certain nodes depending on whether or not they are “overfed” or “underfed”. [0056-0058], signalling to entities that serve nodes (may be base stations) to reallocate resources to their nodes based on earlier reconfiguration determination. The signal may be a QoS notification as it relates to the reallocation of resources for the purposes of QoS improvements).
Regarding claim 11, Ranganath teaches the limitations:
“A wireless communication system, comprising: a set of radio nodes; a controller; a base station communicably coupled to the set of radio nodes and the controller; and a core network communicably coupled to the base station and the controller; wherein the controller is configured to obtain, for the set of radio nodes, enrichment information for a plurality of radio nodes included in the set of radio nodes”, ([0025] describes cells (nodes) as being able to be connected to a gNB (base stations). [0053], RIC functionality in O-RAN is disclosed. [0054] discloses that xApps manager 425 is an application for use on a computer that can collect E2 (enrichment) measurement data from xApps 420 or nodes in an O-RAN framework. [0055], xApp manager can collect QoS requirements (equivalent to profiles),
“wherein the controller is configured to obtain, for the plurality of radio nodes included in the set of radio nodes, corresponding intended quality of service profiles” ([0055], xApp manager can collect QoS requirements (equivalent to profiles),
“wherein the controller is configured to execute an application” ([0054], xApps manager),
“wherein: (i) the application is configured to determine, using the obtained enrichment information, a first subset of radio nodes included in the set of radio nodes, wherein each radio node in the first subset has, or is approaching, an unmet QoS state relative to the corresponding QoS policy of the radio node in the first subset, and/or (ii) the controller is configured to determine, via executing the application, using the obtained enrichment information, a second subset of radio nodes included in the set of radio nodes, wherein each radio node in the second subset has, or is approaching, an excess QoS state relative to the corresponding QoS policy of the radio node in the second subset” ([0068] determine which nodes are “overfed” with resources / congestion, and also determine which nodes are “underfed” with resources / having low user data volumes),
“wherein an excess QoS state is one in which a given radio node in the second subset can be downgraded or disabled for a duration” ([0068] determine which nodes are “overfed” with resources / congestion, and also determine which nodes are “underfed” with resources / having low user data volumes),
“wherein the controller is configured to update, via executing the application, a QoS policy for the plurality of radio nodes included in the set of radio nodes based on the determined first subset of radio nodes and/or the determined second subset of radio nodes, wherein the updating includes improving the QoS policy related to a first radio node in the plurality of radio nodes, and/or downgrading the corresponding QoS policy related to a second radio node in the plurality of radio nodes” (([0068], scale up or scale down QoS policy (resource allocation plan) for certain nodes depending on whether or not they are “overfed” or “underfed”),
“wherein the controller is configured to reconfigure the base station coupled to the radio nodes comprised in the set of radio nodes based on the updated QoS policy” (([0056-0058], signalling to entities that serve nodes (may be base stations) to reallocate resources to their nodes based on earlier reconfiguration determination. The signal may be a QoS notification as it relates to the reallocation of resources for the purposes of QoS improvements),
and wherein the controller is configured to transmit at least one message to a radio node included in the set of radio nodes, wherein the at least one message includes a QoS notification for changing a QoS policy of the radio node included in the set of radio nodes” ([0056-0058], signalling to entities that serve nodes (may be base stations) to reallocate resources to their nodes based on earlier reconfiguration determination. The signal may be a QoS notification as it relates to the reallocation of resources for the purposes of QoS improvements).
Regarding claim 12, Ranganthan teaches the limitations:
“wherein the base station coupled to the radio nodes included in the set of radio nodes, based on the updated QoS policy, is further configured to: communicate, to the controller, a set of vacated physical resource blocks based on an ordered list of the radio nodes in the second subset of radio nodes” ([0056], various predictions for how to allocate (vacate) resources (physical resource blocks) through correlations (may include KPMs such as radio resource utilization, which fundamentally includes vacated PRBs).
“and wherein the controller is configured to indicate to the base station a set of vacated physical resource blocks assigned to one or more radio nodes registered in the first subset of radio nodes” ([0056], various predictions for how to allocate (vacate) resources (physical resource blocks) through correlations (may include KPMs such as radio resource utilization, which fundamentally includes vacated PRBs).
Regarding claim 13, Ranganthan teaches the limitation:
“wherein the base station is configured to receive at least one base station reconfiguration message generated in the core network based on the updated QoS policy, and reconfigure the base station using the base station reconfiguration message to enforce the updated QoS policy on the radio nodes included in the set of radio nodes” ([0053] The non-RT RIC 412 also guides the near-RT RIC 414 using Al policies 441 with possible inclusion of scope identifiers (e.g., Single Network Slice Selection Assistance Information (S- NSSAI), QoS Flow IDs, and/or the like) and statements (e.g., KPI targets, SLAs, and/or the like). The near-RT RIC 414 obtains policies 441 over an interface. Policies 441 may include QoS requirements as stated in [0047]. [0055-0058], QoS requirement-based resource allocation decisions within the near-RT RIC 414 may be conveyed using messages or message flows).
Regarding claim 14, Ranganthan teaches the limitation:
“wherein: (i) at least one radio node in the set of radio nodes is included in a mobile telephone, an automated mobile robot, or a vehicle, and/or (ii) the controller is included in an Open Radio Access (O-RAN)” ([0093], a node may be a vehicle system. [0009] discloses that a UE may be a node).
Regarding claim 15, Ranganthan teaches the limitations:
“A non-transitory computer program element on which are stored machine readable instructions radio node prioritization in a radio system, the machine readable instructions, when executed by a processor, causing the processor to perform the following steps: obtaining, for a set of radio nodes communicably coupled to a base station, enrichment information for a plurality of radio nodes included in the set of radio nodes” ([0025] describes cells (nodes) as being able to be connected to a gNB (base stations). [0060], a compute node hosts xApp manager. [0260] discloses that a compute node may include software and programmable logic (relating to the xApp manager). [0054] discloses that the xApps manager 425 is an application for use on a computer that can collect E2 (enrichment) measurement data from xApps 420 or nodes in an O-RAN framework),
“obtaining, for the plurality of radio nodes included in the set of radio nodes, corresponding intended quality of service (QoS) profiles” ([0055] xApp manager can collect QoS requirements (equivalent to profiles),
“determining, using the obtained enrichment information: a first subset of radio nodes included in the set of radio nodes, wherein each radio node in the first subset has, or is approaching, an unmet QoS state relative to the corresponding QoS policy of the radio node in the first subset, and/or a second subset of radio nodes included in the set of radio nodes wherein each radio node in the second subset has, or is approaching, an excess QoS state relative to the corresponding QoS policy of the radio node in the second subset, wherein an excess QoS state is one in which a given radio node in the second subset can be downgraded or disabled for a duration” ([0068] determine which nodes are “overfed” with resources / congestion, and also determine which nodes are “underfed” with resources / having low user data volumes. [0068] also discloses to scale up or scale down (downgrade) QoS policy (resource allocation plan) for certain nodes depending on whether or not they are “overfed” or “underfed”),
“updating a QoS policy for the plurality of radio nodes included in the set of radio nodes based on the determined first subset of radio nodes and/or the determined second subset of radio nodes, wherein the updating includes improving the corresponding QoS policy related to a first radio node in the plurality of radio nodes, and/or downgrading the corresponding QoS policy related to a second radio node in the plurality of radio nodes; reconfiguring the base station coupled to the radio nodes included in the set of radio nodes based on the updated QoS policy”, ([0068], scale up or scale down QoS policy (resource allocation plan) for certain nodes depending on whether or not they are “overfed” or “underfed”. [0056-0058] discloses to signal to entities that serve nodes (may be base stations) to reallocate resources to their nodes based on earlier reconfiguration determination. The signal may be a QoS notification as it relates to the reallocation of resources for the purposes of QoS improvements),
“and transmitting at least one message to a radio node included in the set of radio nodes, wherein the at least one message includes a QoS notification for changing a QoS policy of the radio node included in the set of radio nodes” ([0056-0058] discloses to signal to entities that serve nodes (may be base stations) to reallocate resources to their nodes based on earlier reconfiguration determination. The signal may be a QoS notification as it relates to the reallocation of resources for the purposes of QoS improvements).
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) 2-4 is/are rejected under 35 U.S.C. 103 as being unpatentable over Ranganath (WO 2023091664 A1) in view of Singh (US 20240129941 A1).
Regarding claim 2, Ranganath differs from the claimed invention in that it does not teach the limitations:
“wherein the determining of the first subset of radio nodes included in the set of radio nodes includes: collecting all radio nodes of the set of radio nodes with, or approaching, an unmet QoS state”,
“for each collected radio node, ranking a severity of the unmet QoS state for the collected radio node”,
“and generating an ordered list of the radio nodes in the first subset of radio nodes ordered from a highest severity of the unmet QoS state to a lowest severity of the unmet QoS state”.
However, pertaining to the same field of invention, Singh teaches the limitations:
“wherein the determining of the first subset of radio nodes included in the set of radio nodes includes: collecting all radio nodes of the set of radio nodes with, or approaching, an unmet QoS state” ([0124], cells in a plurality of radio cells are monitored (collected) based on multiple key factors, which may include Quality of Service class identifier (QCI). A quality of service class identifier is a value (from 1-9, lowest means the cell requires more priority, or is in an unmet state) that tells if a cell should have higher priority or lower priority, essentially acting as a QoS state as to whether or not a node is in need of more resources. Thus, the cells collected may be of a lower QCI, or an unmet QoS state),
“for each collected radio node, ranking a severity of the unmet QoS state for the collected radio node” ([0162] weights can be assigned to cells (nodes), essentially acting as a ranking system that contributes to the cell’s priority),
“and generating an ordered list of the radio nodes in the first subset of radio nodes ordered from a highest severity of the unmet QoS state to a lowest severity of the unmet QoS state” ([0175], optimum core allocation schedule includes the cells ranked by priority (weights based on QCI / QoS as described in [0124] and [0162]).
Therefore, it would have been obvious to one of ordinary skill in the field of the claimed invention before the effective filing date to combine the limitations of Ranganath with those of Singh, for the advantage of increasing network efficiency by dynamically reallocating resources (PRBs) to nodes that are more in need of them based on a QoS list.
Regarding claim 3, Ranganath differs from the claimed invention in that it does not teach the limitations:
“wherein determining of the second subset of radio nodes included in the set of radio nodes includes: collecting all radio nodes of the set of radio nodes with an excess QoS state”,
“for each collected radio node, ranking a severity of the excess QoS state for the collected radio node”,
“and generating an ordered list of the radio nodes in the second subset of radio nodes ordered from a highest amount of excess QoS state to a lowest amount of excess QoS state”.
However, pertaining to the same field of invention, Singh teaches the limitations:
“wherein determining of the second subset of radio nodes included in the set of radio nodes includes: collecting all radio nodes of the set of radio nodes with an excess QoS state” ([0124], cells in a plurality of radio cells are monitored (collected) based on multiple key factors, which may include Quality of Service class identifier (QCI). A quality of service class identifier is a value (from 1-9, highest means the cell requires less priority, or is in an unmet state) that tells if a cell should have higher priority or lower priority, essentially acting as a QoS state as to whether or not a node is in need of more resources. Thus, the cells collected may be of a higher QCI, or an excess QoS state),
“for each collected radio node, ranking a severity of the excess QoS state for the collected radio node” ([0162] weights can be assigned to cells (nodes), essentially acting as a ranking system that contributes to the cell’s priority),
“and generating an ordered list of the radio nodes in the second subset of radio nodes ordered from a highest amount of excess QoS state to a lowest amount of excess QoS state” ([0175], optimum core allocation schedule (list) includes the cells ranked by priority (weights based on QCI / QoS as described in [0124] and [0162]).
Therefore, it would have been obvious to one of ordinary skill in the field of the claimed invention before the effective filing date to combine the limitations of Ranganath with those of Singh, for the advantage of increasing network efficiency by compiling all nodes that are “overfed” (excess QoS state).
Regarding claim 4, Ranganath differs from the claimed invention in that it does not teach the limitations:
“wherein reconfiguring the base station coupled to the radio nodes included in the set of radio nodes based on the updated QoS policy further includes: computing a set of vacated physical resource blocks based on the ordered list of the radio nodes in the second subset of radio nodes” ([0162-0165], resources (PRBs) are assigned (vacated) to cells in decreasing order of priority, which is derived from a cell’s weight. QCI of a cell can factor into its weight value),
“indicating to the base station the set of vacated physical resource blocks; indicating to the base station the ordered list of the radio nodes in the first subset of radio nodes” ([0063], CPO handles resource (PRB) allocation, and can be a network entity (base station). [0164-0165], CS (part of the CPO, which may be a base station), receives cell resource requirements (PRBs that are being reallocated or vacated) from CP (compute predictor)).
Therefore, it would have been obvious to one of ordinary skill in the field of the claimed invention before the effective filing date to combine the limitations of Ranganath with those of Singh, for the advantage of increasing network efficiency by indicating to the base station (or some other serving network entity) how many resources (PRBs) to allocate or vacate to accommodate unmet QoS state nodes.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to BENJAMIN H NGUYEN whose telephone number is (571)482-9975. The examiner can normally be reached Monday-Friday 8am-5pm.
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, Yuwen Pan can be reached at 571-272-7855. 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.
/BENJAMIN H. NGUYEN/Examiner, Art Unit 2649 /YUWEN PAN/Supervisory Patent Examiner, Art Unit 2649