DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 06/02/2026 has been entered.
Response to Arguments
Applicant’s arguments/remarks made in an amendment filed May 8, 2026 have been fully considered. In view of the amended claims 1, 4, 14, 25 and 28 and upon further consideration, a new ground(s) of rejection, necessitated by the amendments is made in view of different interpretation of the previously applied references and new prior art as presented in this Office action. Applicant’s arguments with respect to claim(s) 1-30 are therefore moot.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claim(s) 1-30 are rejected under 35 U.S.C. 103 as being unpatentable over US 20210399954 A1 (Dabell et al.) (hereinafter Dabell) in view of US 20230171592 A1 (HAN et al.) (hereinafter HAN) and in further view of US 20230113519 A1 (Fernandez Alonso et al.) (hereinafter Alonso).
In re claims 1, 14, 25 and 28, Dabell discloses a method (Fig. 5, [0003], “The method also includes using the orchestrator application, executing within the container runtime, to retrieve a system image from a file repository. The system image comprises configuration data for the programmable hardware accelerator to operate according to the configuration data of the retrieved system image”) and an apparatus (Fig. 4, [0055], “FIG. 4 is a block diagram of an example architecture 400 including a distributed computing system implementing a method for scheduling services and orchestrating a configuration of a programmable accelerator 140”) for wireless communication at an accelerator associated with a distributed unit of a radio access network (RAN) (Fig. 6:140A, 610A, [0078], “FIG. 6 is a block diagram of an example architecture 600 implementing a software-as-a-service on a distributed computing system including orchestrator logic for configuring a programmable accelerator. A provider of a software-as-a-service may host a software application at a datacenter and allow tenants (e.g., customers) to access the software using a network connection”), comprising: at least one processor (Fig. 4:120); at least one memory (Fig. 4:130) coupled with the at least one processor; and instructions stored in the at least one memory and executable by the at least one processor ([0021], “The processor 120 can be used to execute computer-executable instructions that are stored in the memory 130 and/or storage 120”) to cause the apparatus to:
communicate context information via a first interface between an application of the distributed unit and an accelerator of the distributed unit ([0003], “The service comprises a software application and an orchestrator application. The orchestrator application is adapted to configure a programmable hardware accelerator. The software application is adapted to interoperate with the programmable hardware accelerator that is configured by the orchestrator application”), wherein the application is configured to communicate, via a second interface, with a radio unit associated with the distributed unit, wherein the accelerator is configured to communicate with the radio unit via a third interface, and wherein the context information comprises a first identifier associated with the accelerator of the distributed unit, a second identifier associated with the application, a third identifier associated with a profile instance associated with the accelerator, a fourth identifier associated with the radio unit associated with the distributed unit, or any combination thereof; and
exchange messages with the accelerator via the first interface between the application and the accelerator based at least in part on the context information ([0034], “As a specific example, the programmable accelerator 140 can be used to process network traffic and the software application can be used to manage network traffic, such that the combination of the programmable accelerator 140 and the software application 134 perform the operations of an application delivery controller. For example, the software application 134 can include modules for customizing the programmable accelerator 140, such as by populating network addresses of an application and its corresponding application servers, supplying credentials and keys, programming DoS vectors, enabling or disabling the offloading cryptographic tasks (such as Transport Layer Security (TLS) encryption and decryption), and monitoring the network traffic. As one example, the software application 134 can communicate with the programmable accelerator 140 by communicating messages across an interconnect of the server computer 110 using a driver (e.g., SR-IOV) of the OS 132”).
Dabell does not explicitly disclose communicate context information via a first interface between an application of the distributed unit and an accelerator of the distributed unit, wherein the application is configured to communicate, via a second interface, with a radio unit associated with the distributed unit, wherein the accelerator is configured to communicate with the radio unit via a third interface; and exchange messages with the accelerator via the first interface between the application and the accelerator based at least in part on the context information.
HAN discloses communicate context information via a first interface between an application of the distributed unit and an accelerator of the distributed unit (Fig. 5, [0004], “In order to improve experience of a UE, it is important that a UE of interest is identified, while connected to the 3GPP network, across SMO/non-RT RIC and Near-RT RIC, and also across O1, A1, and E2 interfaces”. [0005], “Based on that, it was proposed to fill the gap, by making RAN nodes update the RAN UE ID of a UE to SMO via O1 and to Near-RT RIC via E2, whenever assigned (or re-assigned) or de-assigned”. [0019], “When a UE accesses a gNB, especially in case of CU-DU split or CP-UP separated, a RAN UE ID is assigned by the gNB-CU-CP and shared with gNB-DU and gNB-CU-UP when the UE context is created”. [0104], “The application processing circuitry 312 may run various applications for the UE 302 that source/sink application data. The application processing circuitry 312 may further implement one or more-layer operations to transmit/receive application data to/from a data network”. [0117], “FIG. 5 provides a high-level view of an Open RAN (O-RAN) architecture 500. The O-RAN architecture 500 includes four O-RAN defined interfaces—namely, the A1 interface, the O1 interface, the O2 interface, and the Open Fronthaul Management (M)-plane interface—which connect the Service Management and Orchestration (SMO) framework 502 to O-RAN network functions (NFs) 504 and the O-Cloud 506”. [0121], “The O-DU 615 is a logical node hosting RLC, MAC, and higher PHY layer entities/elements (High-PHY layers) based on a lower layer functional split”. [0133], “The non-RT RIC 612 can be an ML training host to host the training of one or more ML models. ML training can be performed offline using data collected from the RIC, O-DU 615 and O-RU 616”. [0135], “The non-RT RIC 62 is be able to access feedback data (e.g., FM and PM statistics) over the O1 interface on ML model performance and perform necessary evaluations...How well the ML model is performing in terms of prediction accuracy or other operating statistics it produces can also be sent to the non-RT RIC 612 over O1” (interface between application and accelerator)), wherein the application is configured to communicate, via a second interface, with a radio unit associated with the distributed unit ([0136], “The A1 interface is between the non-RT RIC 612 (within or outside the SMO 602) and the near-RT RIC 614. The A1 interface supports three types of services as defined in [O14], including a Policy Management Service, an Enrichment Information Service, and ML Model Management Service” (interface between application and RU)), wherein the accelerator is configured to communicate with the radio unit via a third interface ([0122], “As shown in FIG. 6, the E2 interface also connects the O-e/gNB 610 to the Near-RT RIC 614” (interface connecting radio unit to accelerator). [0132], “The O-RAN near-RT RIC 614 is a logical function that enables near-real-time control and optimization of RAN elements and resources via fine-grained data collection and actions over the E2 interface”); and exchange messages with the accelerator via the first interface between the application and the accelerator based at least in part on the context information (Fig. 9, [0147], “Another such process is depicted in FIG. 9, which may be performed by a near-real time RAN intelligent controller (near-RT RIC) in some embodiments. In this example, the process includes, at 905, encoding a message to a next-generation NodeB (gNB) that includes a subscription or request for updated radio access network (RAN) user equipment (UE) identification (ID) information. The process further includes, at 910, receiving, over an E2 interface, a response that includes the updated RAN UE ID information”).
It would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Dabell with HAN to provide techniques for efficient communication exchange such as data models between intermediary computing devices such as an application and accelerator of a distributed unit (DU). The advantage of doing so is potentially increase the scalability, availability, security, and/or performance of the client-server architecture as the number of client devices seeking access to the application server computers increases.
Dabell and HAN do not explicitly disclose wherein the context information comprises a first identifier associated with the accelerator of the distributed unit, a second identifier associated with the application, a third identifier associated with a profile instance associated with the accelerator, a fourth identifier associated with the radio unit associated with the distributed unit, or any combination thereof.
Alonso discloses wherein the context information comprises a first identifier associated with the accelerator of the distributed unit, a second identifier associated with the application (Fig. 6, [0020], “These exemplary methods can include, during establishment of a PDU session for a UE, determining one or more UE application descriptors that correspond to a network application identifier (AppId) of a service data flow (SDF) template for the PDU session. Each UE application descriptor includes a first identifier (OSId) of a UE-supported operating system (OS), and a second identifier (OSAppId) of an application for the UE-supported OS identified by the first identifier”), a third identifier associated with a profile instance associated with the accelerator ([0084], “To determine the operating system of the UE, the PCF may use a Permanent Equipment Identifier (PEI) for the UE that is provided by the AMF and/or an OSId provided by the UE”, a fourth identifier associated with the radio unit associated with the distributed unit (Fig. 9:9200, [0122], “In 542a, the PCF can retrieve the identifiers of the one or more UE-supported OS from a user data repository (UDR) of the communication network. In 542b, the PCF can, when the identifiers are unavailable from the UDR, determine the identifiers based on a permanent equipment identifier (PEI) of the UE obtained from the SMF”), or any combination thereof ([0034], “These and other described embodiments facilitate a single configuration point in the network for application descriptor (e.g., OSId+OSAppId) information related to a UE. For example, AppId to OSAppId mapping is centralized in the PCF”).
It would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Dabell and HAN with Alonso to provide techniques for efficient communication exchange such as data models between intermediary computing devices such as an application and accelerator of a distributed unit (DU). The advantage of doing so is potentially increase the scalability, availability, security, and/or performance of the client-server architecture as the number of client devices seeking access to the application server computers increases.
In re claims 2, 15, 26 and 29, the combination discloses the apparatus of claim 1, the apparatus of claim 14, the method of claim 25 and the method of claim 28, wherein HAN discloses wherein exchanging the messages further comprises: obtaining the context information from the application ([0018], “It would not be desirable for Near-RT RIC to maintain, for every single RAN node, UE contexts of all the UEs and their RAN UE IDs connected to it”. [0104], “The UE 302 may include a host platform 308 coupled with a modem platform 310. The host platform 308 may include application processing circuitry 312, which may be coupled with protocol processing circuitry 314 of the modem platform 310. The application processing circuitry 312 may run various applications for the UE 302 that source/sink application data”); and providing, to the application based at least in part on obtaining the context information, information associated with a data model hosted at the accelerator ([0131], “The O-RAN Non-Real Time (RT) RAN Intelligent Controller (RIC) 612 is a logical function within the SMO framework 502, 602 that enables non-real-time control and optimization of RAN elements and resources; AI/machine learning (ML) workflow(s) including model training, inferences, and updates; and policy-based guidance of applications/features in the Near-RT RIC 614”. [0133], “The non-RT RIC 612 can be an ML training host to host the training of one or more ML models. ML training can be performed offline using data collected from the RIC, O-DU 615 and O-RU 616”. [0135], “The non-RT RIC 62 is be able to access feedback data (e.g., FM and PM statistics) over the O1 interface on ML model performance and perform necessary evaluations” (providing feedback to the application based on data model at the accelerator)).
In re claims 3, 16, 27 and 30, the combination discloses the apparatus of claim 1, the apparatus of claim 14, the method of claim 25 and the method of claim 28, wherein HAN discloses to provide the context information to the application ([0018], “It would not be desirable for Near-RT RIC to maintain, for every single RAN node, UE contexts of all the UEs and their RAN UE IDs connected to it”. [0104], “The UE 302 may include a host platform 308 coupled with a modem platform 310. The host platform 308 may include application processing circuitry 312, which may be coupled with protocol processing circuitry 314 of the modem platform 310. The application processing circuitry 312 may run various applications for the UE 302 that source/sink application data; and obtain, from the application based at least in part on providing the context information, information associated with a data model for communications between the accelerator and the radio unit associated with the distributed unit ([0131], “The O-RAN Non-Real Time (RT) RAN Intelligent Controller (RIC) 612 is a logical function within the SMO framework 502, 602 that enables non-real-time control and optimization of RAN elements and resources; AI/machine learning (ML) workflow(s) including model training, inferences, and updates; and policy-based guidance of applications/features in the Near-RT RIC 614”. [0133], “The non-RT RIC 612 can be an ML training host to host the training of one or more ML models. ML training can be performed offline using data collected from the RIC, O-DU 615 and O-RU 616”. [0135], “The non-RT RIC 62 is be able to access feedback data (e.g., FM and PM statistics) over the O1 interface on ML model performance and perform necessary evaluations” (obtaining information for data model for communications between the accelerator and the RU associated with the DU)).
In re claim 4, the combination discloses the apparatus of claim 3, wherein HAN discloses wherein the instructions are further executable by the at least one processor to cause the apparatus to: provide, to the radio unit via the second interface between the application and the radio unit, a request for the information (Fig. 1, [0004], “In order to improve experience of a UE, it is important that a UE of interest is identified, while connected to the 3GPP network, across SMO/non-RT RIC and Near-RT RIC, and also across O1, A1, and E2 interfaces”. [0051], “This RIC Event Trigger Definition style allows to select a specific target using: [0052] Network Interface Type IE used to select a specific interface type”. [0064], “Some examples of implementations for O-RAN E2 interface AP (Application Protocol) specification are as follows...”); and obtain the information from the radio unit via the second interface and in response to the request, wherein the information from the radio unit is further conveyed to the accelerator via the first interface between the application and the accelerator (Table 8, [0135], “How well the ML model is performing in terms of prediction accuracy or other operating statistics it produces can also be sent to the non-RT RIC 612 over O1”. [0136], “The A1 interface is between the non-RT RIC 612 (within or outside the SMO 602) and the near-RT RIC 614. The A1 interface supports three types of services as defined in [O14], including a Policy Management Service, an Enrichment Information Service, and ML Model Management Service”. [0072], “In embodiments in which the RAN 204 includes a plurality of ANs, they may be coupled with one another via an X2 interface or an Xn interface. The X2/Xn interfaces, which may be separated into control/user plane interfaces in some embodiments, may allow the ANs to communicate information related to handovers, data/context transfers, mobility, load management, interference coordination, etc.”).
In re claims 5 and 17, the combination discloses the apparatus of claim 3 and the apparatus of claim 16, wherein HAN discloses wherein the instructions are further executable by the at least one processor to cause the apparatus to: obtain, from the accelerator based at least in part on providing the information, a first message indicating a result of a validation procedure associated with the information ([0135], “ The non-RT RIC 62 is be able to access feedback data (e.g., FM and PM statistics) over the O1 interface on ML model performance and perform necessary evaluations. If the ML model fails during runtime, an alarm can be generated as feedback to the non-RT RIC 612. How well the ML model is performing in terms of prediction accuracy or other operating statistics it produces can also be sent to the non-RT RIC 612 over O1” (receiving result of validation procedure from the accelerator)).
In re claims 6 and 18, the combination discloses the apparatus of claim 5 and the apparatus of claim 17, wherein HAN discloses wherein the first message indicates a failure of the validation procedure, and the instructions are further executable by the at least one processor to cause the apparatus to: provide, to the accelerator in response to the failure, a second message instructing the accelerator to convey additional information regarding the failure associated with the context information; and obtain, from the accelerator in response to the second message, a third message comprising the additional information associated with the context information, for the communications between the accelerator and the radio unit ([0133], “For reinforcement learning, the ML training host and ML model host/actor may be co-located as part of the non-RT RIC 612 and/or the near-RT RIC 614”. [0135], “The non-RT RIC 62 is be able to access feedback data (e.g., FM and PM statistics) over the O1 interface on ML model performance and perform necessary evaluations. How well the ML model is performing in terms of prediction accuracy or other operating statistics it produces can also be sent to the non-RT RIC 612 over O1” (receiving additional information regarding failure, reinforcement learning)).
In re claims 7 and 19, the combination discloses the apparatus of claim 6 and the apparatus of claim 18, wherein HAN discloses wherein the instructions are further executable by the at least one processor to cause the apparatus to: obtain, based at least in part on the additional information, second additional information for a second data model; and provide, to the accelerator, a fourth message conveying the second additional information ([0133], “The non-RT RIC 612 can be an ML training host to host the training of one or more ML models. ML training can be performed offline using data collected from the RIC, O-DU 615 and O-RU 616. For supervised learning, non-RT RIC 612 is part of the SMO 602, and the ML training host and/or ML model host/actor can be part of the non-RT RIC 612 and/or the near-RT RIC 614. For unsupervised learning, the ML training host and ML model host/actor can be part of the non-RT RIC 612 and/or the near-RT RIC 614. For reinforcement learning, the ML training host and ML model host/actor may be co-located as part of the non-RT RIC 612 and/or the near-RT RIC 614. In some implementations, the non-RT RIC 612 may request or trigger ML model training in the training hosts regardless of where the model is deployed and executed. ML models may be trained and not currently deployed’).
In re claim 8, the combination discloses the apparatus of claim 5, wherein HAN discloses wherein the first message indicates a failure of the validation procedure, and the instructions are further executable by the at least one processor to cause the apparatus to: provide, to the accelerator based at least in part on the failure, a second message identifying additional information for a second data model, wherein the additional information comprises a modified version of the information ([0133], “The non-RT RIC 612 can be an ML training host to host the training of one or more ML models. ML training can be performed offline using data collected from the RIC, O-DU 615 and O-RU 616”. [0134], “In some implementations, the non-RT RIC 612 provides a query-able catalog for an ML designer/developer to publish/install trained ML models (e.g., executable software components). In these implementations, the non-RT RIC 612 may provide discovery mechanism if a particular ML model can be executed in a target ML inference host (MF), and what number and type of ML models can be executed in the MF. For example, there may be three types of ML catalogs made discoverable by the non-RT RIC 612: a design-time catalog (e.g., residing outside the non-RT RIC 612 and hosted by some other ML platform(s)), a training/deployment-time catalog (e.g., residing inside the non-RT RIC 612), and a run-time catalog (e.g., residing inside the non-RT RIC 612). The non-RT RIC 612 supports necessary capabilities for ML model inference in support of ML assisted solutions running in the non-RT RIC 612 or some other ML inference host. These capabilities enable executable software to be installed such as VMs, containers, etc. The non-RT RIC 612 may also include and/or operate one or more ML engines, which are packaged software executable libraries that provide methods, routines, data types, etc., used to run ML models. The non-RT RIC 612 may also implement policies to switch and activate ML model instances under different operating conditions” (modified version of the information)).
In re claim 9, the combination discloses the apparatus of claim 5, wherein HAN discloses wherein the first message indicates a failure of the validation procedure, and the instructions are further executable by the at least one processor to cause the apparatus to: obtain, from the accelerator based at least in part on the failure, an indication of additional information for a second data model, the additional information for producing a modified version of the information ([0135], “ The non-RT RIC 62 is be able to access feedback data (e.g., FM and PM statistics) over the O1 interface on ML model performance and perform necessary evaluations”. [0133], “For reinforcement learning, the ML training host and ML model host/actor may be co-located as part of the non-RT RIC 612 and/or the near-RT RIC 614”. [0134], “In some implementations, the non-RT RIC 612 provides a query-able catalog for an ML designer/developer to publish/install trained ML models (e.g., executable software components). In these implementations, the non-RT RIC 612 may provide discovery mechanism if a particular ML model can be executed in a target ML inference host (MF), and what number and type of ML models can be executed in the MF. For example, there may be three types of ML catalogs made discoverable by the non-RT RIC 612: a design-time catalog (e.g., residing outside the non-RT RIC 612 and hosted by some other ML platform(s)), a training/deployment-time catalog (e.g., residing inside the non-RT RIC 612), and a run-time catalog (e.g., residing inside the non-RT RIC 612). The non-RT RIC 612 supports necessary capabilities for ML model inference in support of ML assisted solutions running in the non-RT RIC 612 or some other ML inference host. These capabilities enable executable software to be installed such as VMs, containers, etc. The non-RT RIC 612 may also include and/or operate one or more ML engines, which are packaged software executable libraries that provide methods, routines, data types, etc., used to run ML models. The non-RT RIC 612 may also implement policies to switch and activate ML model instances under different operating conditions” (modified version of the information)).
In re claim 20, the combination discloses the apparatus of claim 14, wherein HAN discloses wherein the instructions are further executable by the at least one processor to cause the apparatus to: obtain, from the application, a first message comprising information relevant to a second data model; determine a failure of a validation procedure associated with the information; and provide, to the application based at least in part on the failure, a second message indicating a third information, wherein the third information is associated with a modified version of the information (See “In re claim 8” and “In re claim 9”. All features are covered in claims 8 and 9).
In re claims 10 and 21, the combination discloses the apparatus of claim 1 and the apparatus of claim 14, wherein HAN discloses wherein the profile instance associated with the accelerator is associated with a carrier, a physical context, a baseband context associated with the accelerator, or any combination thereof ([0073], “The UE 202 may be simultaneously connected with a plurality of cells provided by the same or different ANs of the RAN 204. For example, the UE 202 and RAN 204 may use carrier aggregation to allow the UE 202 to connect with a plurality of component carriers” (profile associated with a carrier)).
In re claims 11 and 22, the combination discloses the apparatus of claim 1 and the apparatus of claim 14, wherein HAN discloses wherein the context information further comprises an indication of applicable antenna panels associated with one or more transmission reception points (Fig. 3, [0107], “The modem platform 310 may further include transmit circuitry 318, receive circuitry 320, RF circuitry 322, and RF front end (RFFE) 324, which may include or connect to one or more antenna panels 326”).
In re claims 12 and 23, the combination discloses the apparatus of claim 1 and the apparatus of claim 14, wherein Alonso discloses wherein the first identifier corresponds to at least two profile instances of a plurality of profiles instances (Fig. 7, [0122], “In 542a, the PCF can retrieve the identifiers of the one or more UE-supported OS from a user data repository (UDR) of the communication network. In 542b, the PCF can, when the identifiers are unavailable from the UDR, determine the identifiers based on a permanent equipment identifier (PEI) of the UE obtained from the SMF”).
In re claims 13 and 24, the combination discloses the apparatus of claim 1 and the apparatus of claim 14, wherein Alonso discloses wherein the context information comprises a first plurality of identifiers associated with a plurality of profile instances associated with the accelerator ([0075], “According to 3GPP TS 23.501, clause 5.32.8, an ATSSS rule sent to the UE includes traffic descriptor information that can include at least one of the following descriptors: [0076] one or more application descriptors (identifying the traffic generating the traffic)”. [0084], “To determine the operating system of the UE, the PCF may use a Permanent Equipment Identifier (PEI) for the UE that is provided by the AMF and/or an OSId provided by the UE”), a second plurality of identifiers associated with a plurality of radio units including the radio unit ([0023], “In some of these embodiments, determining the identifiers can include one of the following: receiving the identifiers from the UE, or deriving the identifiers based on a permanent equipment identifier (PEI), of the UE, that was obtained from an access and mobility management function (AMF) of the communication network”), a third plurality of identifiers associated with a plurality of applications including the application ([0020], “These exemplary methods can include, during establishment of a PDU session for a UE, determining one or more UE application descriptors that correspond to a network application identifier (AppId) of a service data flow (SDF) template for the PDU session. Each UE application descriptor includes a first identifier (OSId) of a UE-supported operating system (OS), and a second identifier (OSAppId) of an application for the UE-supported OS identified by the first identifier”), or any combination thereof.
Contact
Any inquiry concerning this communication or earlier communications from the examiner should be directed to SWATI JAIN whose telephone number is (571)270-0699. The examiner can normally be reached Mon - Fri (830 am - 530 pm).
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, Pan Yuwen can be reached on 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.
/SWATI JAIN/Examiner, Art Unit 2649 /YUWEN PAN/Supervisory Patent Examiner, Art Unit 2649
Prosecution Insights