DETAILED ACTION
This office action is in response to the application filed on 10/24/2024.
Claims 1-17 are cancelled.
Claims 18-33 are 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 .
Information Disclosure Statement
The information disclosure statement (IDS) submitted on 10/24/2024 is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
Claim Interpretation
The following is a quotation of 35 U.S.C. 112(f):
(f) Element in Claim for a Combination. – An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The following is a quotation of pre-AIA 35 U.S.C. 112, sixth paragraph:
An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
This application includes one or more claim limitations that do not use the word “means,” but are nonetheless being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, because the claim limitation(s) uses a generic placeholder that is coupled with functional language without reciting sufficient structure to perform the recited function and the generic placeholder is not preceded by a structural modifier. Such claim limitation(s) is/are: “a controller configured to configure the radio resource configuration information in the UE and distinctly processing user plane data of application data based on the radio resource configuration information” in claim 28. Para.0272 “In addition, the terms …"controller", … may generally mean computer-related entity hardware, a combination of hardware and software, software, or running software.”
Because this/these claim limitation(s) is/are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, it/they is/are being interpreted to cover the corresponding structure described in the specification as performing the claimed function, and equivalents thereof.
If applicant does not intend to have this/these limitation(s) interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, applicant may: (1) amend the claim limitation(s) to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph (e.g., by reciting sufficient structure to perform the claimed function); or (2) present a sufficient showing that the claim limitation(s) recite(s) sufficient structure to perform the claimed function so as to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph.
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) 18, 24, 28 is/are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Park et al. (hereinafter Park, US 2019/0124572 A1).
Regarding Claim 18, Park discloses A method for processing an application data flow by a user equipment (UE) (Park: para.0152 “ The 5GC may be able to trigger a specific application in the wireless device 1500 (e.g., after a request from an application server). If receiving that trigger message, the wireless device 1500 may pass it to the identified application in the wireless device 1500. The identified application in the wireless device 1500 may establish a PDU session to a specific DNN.” Para.0340 “FIG. 34 shows an example message flow for establishing an Ethernet type PDU session with handover.” Processing application data by a wireless device in a PDU session), the method comprising:
receiving a higher layer message including radio resource configuration information associated with protocol data unit (PDU) set information or assistance information (Park: para.0341 “At step 3403, the first base station 3420 may transmit Ethernet type bearer configuration parameters to the wireless device 3410 via an RRC message (e.g., RRC reconfiguration message). The RRC message may comprise one or more of a bearer identifier of the Ethernet type bearer, bearer type information (indicating the Ethernet type bearer is Ethernet type), QoS information, priority information, logical channel information, PDCP configuration parameters, RLC configuration parameters, header compression information, etc. The PDCP configuration parameters may comprise one or more PDCP header compression profile information.” radio resource configuration information associated with assistance information is obtained, that is each of the configuration parameters are information used to configure the radio resource. Examiner notes that the higher layer message can be an RRC message in para.0119 of applicant’s specification “the higher layer message may be an RRC message”, para.0107 defined a PDU set as “(A PDU Set is composed of one or more PDUs…” and para.0115 shows that the assistance information within the radio resource configuration information may be traffic characteristics “radio resource configuration information may include at least one of assistance
information for an application traffic characteristic”, in this case QoS information and channel information.);
configuring the radio resource configuration information in the UE (Park: para.0342 “The wireless device 3410 may configure (e.g., based on one or more elements of the RRC message) one or more parameters associated with one or more bearers and/or one or more PDU sessions of an Ethernet type” parameters of the UE are configured based on the obtained information in RRC message.); and
distinctly processing user plane data of application data based on the radio resource configuration information (Park: para.0152 “The identified application in the wireless device 1500 may establish a PDU session to a specific DNN.” Para.0340 “FIG. 34 shows an example message flow for establishing an Ethernet type PDU session with handover.” para.0341 “At step 3403, the first base station 3420 may transmit Ethernet type bearer configuration parameters to the wireless device 3410 via an RRC message (e.g., RRC reconfiguration message).” para.0342 “The wireless device 3410 may configure (e.g., based on one or more elements of the RRC message) one or more parameters associated with one or more bearers and/or one or more PDU sessions of an Ethernet type. At step 3404, the wireless device 3410 may transmit, to the base station 3420, one or more Ethernet frames based on one or more elements of the RRC message. The base station may forward the one or more Ethernet frames towards a user plane core network entity (e.g., UPF, serving gateway, PDN gateway, etc.). The one or more Ethernet frames may comprise a MAC address of the wireless device 3410. The wireless device 3410 may compress headers of the one or more Ethernet frames (e.g., based on header compression parameters indicated in the RRC message).” fig. 34 is a process for a PDU session, and as seen in para.0152 the PDU session may be for a the data of a particular application. User plane data of Application data, the frames that are sent to the user plane core network entity, are processed in view of the RRC message and transmitted, for example at leas headers are modified. See also para.0298, and para.0334 “The target base station 3340 may employ the wireless device configuration information and/or wireless device capability information of the wireless device 3310 to properly configure wireless device configuration and/or one or more bearer configurations (e.g., PDU session configurations, QoS flow configurations) before the wireless device 3310 connects to the target base station 3340.”).
Regarding Claim 24 Park discloses A method for processing an application data flow by a base station (Park: para.0341 first base station 3420), the method comprising: transmitting, to a user equipment (UE), a higher layer message including radio resource configuration information associated with protocol data unit (PDU) set information or assistance information (Park: para.0341 “At step 3403, the first base station 3420 may transmit Ethernet type bearer configuration parameters to the wireless device 3410 via an RRC message (e.g., RRC reconfiguration message). The RRC message may comprise one or more of a bearer identifier of the Ethernet type bearer, bearer type information (indicating the Ethernet type bearer is Ethernet type), QoS information, priority information, logical channel information, PDCP configuration parameters, RLC configuration parameters, header compression information, etc. The PDCP configuration parameters may comprise one or more PDCP header compression profile information.” radio resource configuration information associated with assistance information is sent by the base station to the UE, that is each of the configuration parameters are information used to configure the radio resource. Examiner notes that the higher layer message can be an RRC message in para.0119 of applicant’s specification “the higher layer message may be an RRC message”, para.0107 defined a PDU set as “(A PDU Set is composed of one or more PDUs…” and para.0115 shows that the assistance information within the radio resource configuration information may be traffic characteristics “radio resource configuration information may include at least one of assistance information for an application traffic characteristic”, in this case QoS information and channel information.); and
distinctly processing user plane data of application data based on the radio resource configuration information (Park: para.0342 “ At step 3404, the wireless device 3410 may transmit, to the base station 3420, one or more Ethernet frames based on one or more elements of the RRC message. The base station may forward the one or more Ethernet frames towards a user plane core network entity (e.g., UPF, serving gateway, PDN gateway, etc.).” para.0357 “ At step 3612, the base station may transmit an RRC message comprising bearer configuration parameters for the PDU session. At step 3615, the base station may transmit and/or receive packets of the PDU session.” Para.0358 “At step 3621, the base station may transmit an RRC message comprising bearer configuration parameters for the Ethernet type PDU session. At step 3624, the base station may transmit and/or receive (e.g., from the wireless device) Ethernet frames of the Ethernet type PDU session. The Ethernet frames may comprised compressed headers comprising source and/or destination MAC addresses.” Based on the radio resource configuration information sent by the base station in Fig. 36 3612/3621 or Fig. 34 3402 that is configured on the UE side for modifying and sending over the PDUs, user plane data PDU frames that are received via ethernet PDU session or PDU session are processed).
Regarding Claim 28, Park discloses A user equipment (UE) processing an application data flow (Park: para.0152 “ The 5GC may be able to trigger a specific application in the wireless device 1500 (e.g., after a request from an application server). If receiving that trigger message, the wireless device 1500 may pass it to the identified application in the wireless device 1500. The identified application in the wireless device 1500 may establish a PDU session to a specific DNN.” Para.0340 “FIG. 34 shows an example message flow for establishing an Ethernet type PDU session with handover.” Processing application data by a wireless device in a PDU session), comprising:
a receiver (Park: Fig. 4 communication interface 407) configured to receive a higher layer message including radio resource configuration information associated with protocol data unit (PDU) set information or assistance information (Park: para.0341 “At step 3403, the first base station 3420 may transmit Ethernet type bearer configuration parameters to the wireless device 3410 via an RRC message (e.g., RRC reconfiguration message). The RRC message may comprise one or more of a bearer identifier of the Ethernet type bearer, bearer type information (indicating the Ethernet type bearer is Ethernet type), QoS information, priority information, logical channel information, PDCP configuration parameters, RLC configuration parameters, header compression information, etc. The PDCP configuration parameters may comprise one or more PDCP header compression profile information.” radio resource configuration information associated with assistance information is obtained, that is each of the configuration parameters are information used to configure the radio resource. Examiner notes that the higher layer message can be an RRC message in para.0119 of applicant’s specification “the higher layer message may be an RRC message”, para.0107 defined a PDU set as “(A PDU Set is composed of one or more PDUs…” and para.0115 shows that the assistance information within the radio resource configuration information may be traffic characteristics “radio resource configuration information may include at least one of assistance information for an application traffic characteristic”, in this case QoS information and channel information.); and
a controller (Park: Fig. 4 processor 408) configured to configure the radio resource configuration information in the UE (Park: para.0342 “The wireless device 3410 may configure (e.g., based on one or more elements of the RRC message) one or more parameters associated with one or more bearers and/or one or more PDU sessions of an Ethernet type” parameters of the UE are configured based on the obtained information in RRC message.) and
distinctly processing user plane data of application data based on the radio resource configuration information (Park: para.0152 “The identified application in the wireless device 1500 may establish a PDU session to a specific DNN.” Para.0340 “FIG. 34 shows an example message flow for establishing an Ethernet type PDU session with handover.” para.0341 “At step 3403, the first base station 3420 may transmit Ethernet type bearer configuration parameters to the wireless device 3410 via an RRC message (e.g., RRC reconfiguration message).” para.0342 “The wireless device 3410 may configure (e.g., based on one or more elements of the RRC message) one or more parameters associated with one or more bearers and/or one or more PDU sessions of an Ethernet type. At step 3404, the wireless device 3410 may transmit, to the base station 3420, one or more Ethernet frames based on one or more elements of the RRC message. The base station may forward the one or more Ethernet frames towards a user plane core network entity (e.g., UPF, serving gateway, PDN gateway, etc.). The one or more Ethernet frames may comprise a MAC address of the wireless device 3410. The wireless device 3410 may compress headers of the one or more Ethernet frames (e.g., based on header compression parameters indicated in the RRC message).” fig. 34 is a process for a PDU session, and as seen in para.0152 the PDU session may be for a the data of a particular application. User plane data of Application data, the frames that are sent to the user plane core network entity, are processed in view of the RRC message and transmitted, for example at leas headers are modified. See also para.0298, and para.0334 “The target base station 3340 may employ the wireless device configuration information and/or wireless device capability information of the wireless device 3310 to properly configure wireless device configuration and/or one or more bearer configurations (e.g., PDU session configurations, QoS flow configurations) before the wireless device 3310 connects to the target base station 3340.”).
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.
Claim(s) 19, 25, 29 is/are rejected under 35 U.S.C. 103 as being unpatentable over Park et al. (hereinafter Park, US 2019/0124572 A1) in view of Baek et al. (hereinafter Baek, US 2023/0309100 A1).
Regarding Claim 19, Park discloses claim 18 as set forth above.
However Park does not explicitly disclose wherein the PDU set information includes at least one of a PDU Set sequence number, PDU Set end PDU indication information, and PDU Set importance information.
Baek discloses wherein the PDU set information includes at least one of a PDU Set sequence number, PDU Set end PDU indication information, and PDU Set importance information (Baek: para.0079 “Meanwhile, the NG-RAN 104 may discard the GTP overhead, include the application level information included in the GTP header in the SDAP to generate a packet data convergence protocol (PDCP) packet, and transfer the generated PDCP packet to the UE 102 (operation 203). The application level information that may be included in the SDAP may include at least one of, e.g., QFI, PDU set ID, application ID, importance information, correlation SN, or correlation rolling SN. FIG. 2 illustrates an example in which a first SDAP 203 a, a second SDAP 203 b, and a third SDAP 203 c each include the QFI, importance information, and correlation rolling SN.” The PDU set ID for the PDU, as well as its importance and sequence number (SN), are provided to the UE.).
Therefore it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Park with Baek in order to incorporate wherein the PDU set information includes at least one of a PDU Set sequence number, PDU Set end PDU indication information, and PDU Set importance information.
One of ordinary skill in the art would have been motivated to combine because of the expected benefit of improving quality of service (Baek: para.0012, para.0045).
Regarding Claims 25 and 29, they do not teach nor further define over the limitations of claim 19, therefore the supporting rationale for the rejection to claim 19 applies equally as well to that of claims 25 and 29.
Claim(s) 20-21, 26-27, 30-31 is/are rejected under 35 U.S.C. 103 as being unpatentable over Park et al. (hereinafter Park, US 2019/0124572 A1) in view of Chen et al. (hereinafter Chen, US 2019/0254117 A1) further in view of Sharma et al. (hereinafter Sharma, US 2021/0227422 A1).
Regarding Claim 20, Park discloses Claim 18 as set forth above.
However Park does not explicitly disclose wherein the radio resource configuration information includes at least one of PDU set discard configuration indication information and discard timer information according to a PDU set importance.
Chen discloses wherein the radio resource configuration information includes at least one of PDU set discard configuration indication information and discard timer information (Chen: para.0163 “Once the RLC entity receives the first or new PDCP PDU discard timer information from the upper layer, the duplicated PDCP PDU that is not delivered to the RLC entity may apply the PDCP PDU discard timer. The value of the PDCP PDU discard timer may be determined based on the received discard timer information (e.g., indicated by a Discard Timer Index or a Discard Timer Value).” Para.0043 “In the following, the PDCP duplication operation for the case of two RLC entities (e.g., the UE is configured with two RLC entities) is introduced for brevity, but it should be noted that implementations of the present disclosure may be also applicable for the more than two RLC entities cases (e.g., the UE is configured with more than two RLC entities).” The RLC of the UE obtains radio resource configuration information of a PDU discard timer).
Therefore it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Park with Chen in order to incorporate wherein the radio resource configuration information includes at least one of PDU set discard configuration indication information and discard timer information.
One of ordinary skill in the art would have been motivated to combine because of the expected benefit of improved reliability of transmission (Chen: para.0003-0004).
However Park-Chen does not explicitly disclose PDU set discard configuration indication information and discard timer information according to a PDU set importance.
Sharma discloses PDU set discard configuration indication information and discard timer information according to a PDU set importance (Sharma: para.0134 “At step 632 the PDCP entity 452 starts a PDCP discard timer in respect of the newly formed second PDCP PDU 418. Reflecting the determination at step 606 that the received second PDCP SDU 416 which forms the second PDCP PDU 418 is associated with the higher priority, the PDCP discard timer is started with a second duration, which is longer than the first duration which would have been assigned to the PDCP discard timer to a PDCP PDU not having the higher priority, as described above in step 616.” The discard timers are set based on priority of each PDU).
Therefore it would have been obvious to one of ordinary skill in the art before the effective filing date to combine Park-Chen with Sharma in order to incorporate PDU set discard configuration indication information and discard timer information according to a PDU set importance, and apply this concept to the discard timers sent in Chen.
One of ordinary skill in the art would have been motivated to combine because of the expected benefit of prioritizing data such that data delivery is not degraded or reduced (Sharma: para.0068).
Regarding Claim 21, Park-Chen-Sharma discloses claim 20 as set forth above.
However Park does not explicitly disclose wherein the PDU set discard configuration identification information is configured in association with a data radio bearer.
Chen discloses wherein the PDU set discard configuration identification information is configured in association with a data radio bearer (Chen: para.0164 “In some implementations, the PDCP PDU discard timer may have different values for different radio bearers (e.g., DRBs). In some implementations, the value of the PDCP PDU discard timer may be different when the PDCP duplication function is activated or deactivated for a certain radio bearer.” The discard timer may be set based on the radio bearer.).
Therefore it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Park with Chen in order to incorporate wherein the PDU set discard configuration identification information is configured in association with a data radio bearer.
One of ordinary skill in the art would have been motivated to combine because of the expected benefit of improved reliability of transmission (Chen: para.0003-0004).
Regarding Claims 26-27, 30-31, they do not teach nor further define over the limitations of claims 20-21, therefore the supporting rationale for the rejections to claims 20-21 apply equally as well to that of claims 26-27 and 30-31.
Claim(s) 22, 32 is/are rejected under 35 U.S.C. 103 as being unpatentable over Park et al. (hereinafter Park, US 2019/0124572 A1) in view of Chun et al. (hereinafter Chun, US 2012/0195276 A1).
Regarding Claim 22, Park discloses claim 18 as set forth above.
However Park does not explicitly disclose wherein distinctly processing, if a packet data convergence protocol (PDCP) discard timer or a discard timer according to a PDU set importance expires for one PDCP service data unit (SDU), discards all PDCP service data units (SDUs) included in the PDU set information to which the one PDCP SDU belongs, along with a PDCP PDU in a PDCP entity.
Chun discloses wherein distinctly processing, if a packet data convergence protocol (PDCP) discard timer or a discard timer according to a PDU set importance (Chun: para.0070 “ In addition, the timer expiration time can be set flexibly according to data type since not all IP packets or PDCP PDUs have the same importance.” Discard timer set based on importance.) expires for one PDCP service data unit (SDU), discards all PDCP service data units (SDUs) included in the PDU set information (Chun: para.0061 “Specifically, the RLC transmitting side constructs a RLC PDU by segmenting and concatenating RLC SDUs received from an upper entity so as to match a MAC PDU size (i.e., a RLC PDU size) indicated by a lower entity. A header of a RLC PDU includes information associated with segmentation, concatenation or the like of RLC SDUs.” The PDU header comprises information regarding set of SDU that comprise the PDU) to which the one PDCP SDU belongs, along with a PDCP PDU in a PDCP entity (Chun: para.0066 “The timer can also run commonly for a specific number of PDCP SDUs or a specific group of PDCP SDUs. For example, when a specific number of related PDCP SDUs or a specific group of PDCP SDUs is present, the timer can run only for the first PDCP SDU.” Para.0068 “When the timer expires while the PDCP entity has not received any notification of whether or not the PDCP PDU has been successfully transmitted from the RLC entity, the PDCP entity can decide to discard a PDCP SDU associated with the timer.” Para.0071 “Preferably, the PDCP entity discards the PDCP PDU associated with the PDCP SDU together with the PDCP SDU.” The discard timer is set for a group of related SDUs in view of the first SDU of the group. When the timer expires, the group of SDUs and associated PDU are discarded.).
Therefore it would have been obvious to one of ordinary skill in the art before the effective filing date to combine Park with Chun in order to incorporate wherein distinctly processing, if a packet data convergence protocol (PDCP) discard timer or a discard timer according to a PDU set importance expires for one PDCP service data unit (SDU), discards all PDCP service data units (SDUs) included in the PDU set information to which the one PDCP SDU belongs, along with a PDCP PDU in a PDCP entity.
One of ordinary skill in the art would have been motivated to combine because of the expected benefit of improving QoS of a wireless mobile communication system (Chun: para.0009).
Regarding Claim 32 it does not teach nor further define over the limitations of claim 22, therefore the supporting rationale for the rejection to claim 22 applies equally as well to that of claim 32.
Claim(s) 23, 33 is/are rejected under 35 U.S.C. 103 as being unpatentable over Park et al. (hereinafter Park, US 2019/0124572 A1) in view of Deng (US 2023/0262793 A1).
Regarding Claim 23, Park disclose claim 18 as set forth above.
However Park does not explicitly disclose wherein the assistance information includes a PDU set delay budget parameter received from a core network node.
Deng discloses wherein the assistance information includes a PDU set delay budget parameter received from a core network node (Deng: para.0257 “Step 404: the SMF sends the determined Uu PDB to be sent to the relay UE to the relay UE.” para.0260 “ It should be noted that the Uu PDB in the embodiment of the disclosure is the communication delay of the communication between the relay UE and the UPF through the Uu interface, and is also understood as the upper limit of the packet transmission delay of the communication between the relay UE and the UPF. That is, the relay UE sends the received high-level data packet (PDU) to the UPF by means of packet within the packet transmission delay determined by the Uu PDB, and the UPF sends the received high-level data packet (PDU) to the relay UE by means of packet within the packet transmission delay determined by the Uu PDB, to achieve the purpose of communicating between the relay UE and the core network. That is to say, the Uu PDB in the embodiment of the disclosure is the communication delay directed at the high-level data packet.” The UE receives from the SMF, a core network entity, a delay budget parameter UU PDB, and PDUs are sent according to this delay budget. Examiner notes that a packet delay budget is a delay budget parameter in applicants specification para.0162 “PDU-Set level Packet Delay Budget”).
Therefore it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Park and Deng in order to incorporate wherein the assistance information includes a PDU set delay budget parameter received from a core network node.
One of ordinary skill in the art would have been motivated to combine because of the expected benefit of improved QoS in communication within a network (Deng: para.0003).
Regarding Claim 33, it does not teach nor further define over the limitations of claim 23, therefore the supporting rationale for the rejection to claim 23 applies equally as well that of claim 33.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Luo et al. US 2025/0330876 A1 see abstract, para.0030 and para.0068, wherein the PDU set information includes discard timer for the PDU set, sent to the UPF.
Xiao et al. US 2016/0352643 A1 see para.0003 for PDU and SDU discard based on discard timer.
Xu et al. US 2021/0051611 A1 see para.0115 PDCP PDU using discard timer between UE and base station
Any inquiry concerning this communication or earlier communications from the examiner should be directed to EUI H KIM whose telephone number is (571)272-8133. The examiner can normally be reached 7:30-5 M-R, M-F alternating.
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, Kamal B Divecha can be reached at 5712725863. 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.
/EUI H KIM/ Examiner, Art Unit 2453
/KAMAL B DIVECHA/ Supervisory Patent Examiner, Art Unit 2453