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 .
The office action is a response to Applicant’s Amendment filed April 7, 2026.
Claims 1, 6, 11, 16 and 17 have been amended.
Claims 5, 15 and 18 have been cancelled.
Claims 1-4, 6-14, 16, 17, 19 and 20 are now pending in the application.
Response to Arguments
Applicant's arguments filed April 7, 2026 in Remarks have been fully considered. Examiner believes that the currently amended claims may be proper to reject with a new grounds of rejection as a final office action. Examiner’s reasoning is as follows.
In the claims filed July 21, 2025, Applicant had recited a process associated with determining a handover failure or a process associated with determining a radio link failure. Examiner had filed a final office action, applying a 35 USC 102 rejection in view of “Liu” (U.S. 20220141735), reasoning its disclosure of each limitation associated with the handover failure determination (“determining a handover failure of a process of attempting to hand over from a source network device to a target network device, wherein the source network device and the target network device are network devices using different communication standards, and generating a first report in response to the determining the handover failure, wherein the first report comprises a container that comprises at least one piece of information related to the handover failure, and the container uses a coding format corresponding to a wireless communication standard of the source network device”), not required to examine the limitations of the radio link failure, which hand been claimed in the alternative.
In Applicant’s amended response filed December 24, 2025, Applicant had recited determining a handover failure or determining a radio link failure; but the handover failure determination had been amended with the limitation of the recited “container” using a coding format corresponding to a wireless communication standard of the source network device “regardless of whether a first network device for receiving the first report is the source network device”. Since “Liu” did not suggest this limitation, Examiner withdrew the rejection and filed another non-final action on January 23, 2026, with new grounds of rejection: 35 USC 103 combination of Liu in view of “Johansson”. Examiner cited Johansson to disclose the radio link failure determination elements; this time, the limitations regarding the handover failure did not need to be examined, and the amendment directed to the recited “container” using a coding format corresponding to a wireless communication standard of the source network device “regardless of whether a first network device for receiving the first report is the source network device” was not required to be disclosed in the grounds of rejection.
The current Applicant’s response filed April 7th is reciting all the limitations associated with the handover failure determination that had been recited in the response on December 24th (“determining a handover failure of a process of attempting to hand over from a source network device to a target network device, wherein the source network device and the target network device are network devices using different communication standards, and generating a first report in response to the determining the handover failure, wherein the first report comprises a container that comprises at least one piece of information related to the handover failure, and the container uses a coding format corresponding to a wireless communication standard of the source network device regardless of whether a first network device for receiving the first report is the source network device”) Now that the limitations associated with the radio link failure have been removed, Examiner believes that now is the first time that the limitation regarding the “container” using a coding format corresponding to a wireless communication standard of the source network device “regardless of whether a first network device for receiving the first report is the source network device” must be considered.
Liu had already been established to disclose all the limitations up to the underlined amendment from prior set of claims. Citing a new reference that is reasoned to disclosed the underlined limitation would make it proper to file a final office action with the new grounds of rejection.
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 (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 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 1-4, 6-14, 16, 17, 19 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Liu et al, U.S. Patent Application Publication No. 20220141735 (hereinafter Liu) in view of Rugeland et al, U.S. Patent Application Publication No. 20220007255 A1 (hereinafter Rugeland).
Regarding Claim 1, Liu discloses a method performed by a terminal device or a chip on the terminal device (e.g., FIG. 4, 8, ¶ [0282], UE 405 may experience an RLF event with the target cell 410 before the handover procedure is initiated or completed), the method comprising: determining a handover failure of a process attempting to hand over from a source network device to a target network device (e.g., ¶ [0010] [0028] [0054] [0306], RLF [determined, reported], RLF event [which] may be a… [inter-RAT] handover failure; e.g., FIG. 4, 8, ¶ [0282], UE 405 may experience an RLF event with the target cell 410 before the handover procedure is initiated or completed), wherein the source network device and the target network device are network devices using different communication standards (e.g., ¶ [0028] [0306], handover between different RATs (e.g., NR to LTE)); and generating a first report in response to the determining the handover failure (e.g., ¶ [0054], RLF report may be configured to indicate … a handover failure; e.g., ¶ [0282] [0315], After successfully reestablishing the RRC connection, UE may transmit an RLF report including RLF information to the source cell); wherein the first report comprises a container that comprises at least one piece of information related to the handover failure (e.g., FIGS. 4, 8, ¶ [0282] [0315], UE may experience an RLF event with the target cell before the handover procedure is initiated or completed… UE may may transmit an RLF report including RLF information to the source cell), and the container uses a coding format corresponding to a wireless communication standard of the source network device (e.g., ¶ [0282] [0315], UE may transmit an RLF report including RLF information to the source cell [Examiner asserts that a report to the source cell by UE over air interface to the cell is implied to be coded in the communication standard used by the source cell. Prior art example, Xu et al, U.S. Patent Application Publication No. 20210144610 A1 (hereinafter Xu, using the prior art date of related Chinese Patent Application Publication No. CN 112788693A) discloses a UE, having determined a RLF related to a handover failure in a system where source and destination cell may be different RATs (e.g., LTE and NR), generates an RLF report to send to a cell, the report format being that of the cell network standard. Particularly, Xu discloses a UE determining a handover related failure in a cell of a base station 1 (e.g., FIG. 3, ¶ [0052]), saving, among other details, the cell identity of the source cell that triggered the handover before failure (e.g. ¶ [0055]), cell identity where UE attempts to reestablish RRC connection after the failure (e.g., ¶ [0062]), and stores the RLF report of which radio access technology the stored RLF report information is, such as an LTE RLF report or an NR RLF report (e.g., ¶ [0064]). If, for example, the base station 1 is an LTE base station, the RLF report information is the “LTE RLF report”, which is in the format and encoding of the LTE RRC (e.g., ¶ [0068])]); and sending the first report to a first network device (e.g., ¶ [0282] [0315], UE transmits an RLF report to the source cell).
Liu does not expressly disclose the container uses a coding format corresponding to a wireless communication standard of the source network device regardless of whether a first network device for receiving the first report is the source network device.
Rugeland discloses the container uses a coding format corresponding to a wireless communication standard of the source network device (e.g., ¶ [0146] Some embodiments disclosed herein provide multiple mechanisms at a UE and a network node for being able to indicate the UE identifier used in Reestablishment procedure in case of inter-RAT reestablishment procedures; ¶ [0147] Determining a set of parameters to be used as a UE identifier and to be included in a re-establishment request message to a second target RAT… The determination may be done upon detecting the failure e.g. radio link failure, handover failure, reconfiguration with sync failure or any other failure or ordinary triggering leading to a re-establishment and initiating reestablishment) regardless of whether a first network device for receiving the first report is the source network device (e.g., ¶ [0153] Some second exemplifying embodiments. Create a new inter-RAT re-establishment request kind of message in each target RAT allowing source RAT parameters, e.g. the C-RNTI and the PCI, in the source RAT format to be transmitted in the second RAT during re-establishment without the need to perform further adjustments [The message in Rugeland is a re-establishment message sent after handover failure. Examiner interprets a re-establishment message as a “first report”; the UE may set the contents of the re-establishment message (e.g., ¶ [0064]) with failure information (e.g., ¶ [0073] [0074]), which Examiner interprets to be a report]; e.g., ¶ [0200] In some embodiments, the wireless device creates and/or uses a new variable or extending an existing variable to comprise the one or more parameters of the first set of parameters in both the format of the first RAT and in the format of the second RAT. The new variable may comprise parameters of only one format as in the legacy scenario or parameters of two or more formats according to embodiments disclosed herein [i.e., Examiner interprets this passage as more closely suggesting that the coding format may be if the first RAT even if the first network device is not the source]).
It would have been obvious to one of ordinary skill in the art at the time of the filing date to combine the disclosure of determining a handover failure on the target network device, as disclosed by Liu, with the disclosure of a coding format corresponding to a wireless communication standard of the source network device regardless of whether a first network device for receiving the first report is the source network device, as disclosed by Rugeland. The motivation to combine would have been to support multi-antenna techniques to increase data rates and reliability of a wireless communication system (Rugeland: e.g., ¶ [0003]).
Regarding Claim 2, Liu in view of Rugeland discloses all the limitations of the method according to claim 1.
Liu discloses wherein the first report further comprises first information, and the first information comprises information that the first report is a report for an inter-radio access technology (inter-RAT) handover scenario (e.g., ¶ [0054], RLF report may be configured to indicate … a handover failure; e.g., ¶ [0083], identifying whether a type of a handover may be an inter-RAT handover).
Regarding Claim 3, Liu in view of Rugeland discloses all the limitations of the method according to claim 1.
Liu discloses wherein the first report further comprises second information, and the second information comprises information that the first report is for an inter-system handover scenario or a report for an intra- system handover scenario (e.g., ¶ [0028] [0083] [0147], [identify] whether a type of a handover may be an inter-RAT handover or an intra-RAT handover, where the RLF report includes an indication of the type of the handover).
Regarding Claim 4, Liu in view of Rugeland discloses all the limitations of the method according to claim 1.
Liu discloses further comprising: sending first indication information to the first network device, wherein the first indication information comprises information that the terminal device records the first report (e.g., ¶ [0040], apparatus receives RLF report [which may be of inter-RAT handover failure (e.g., ¶ [0028])]); and receiving second indication information from the first network device, wherein the second indication information comprises information for the terminal device to report the first report (e.g., ¶ [0040], apparatus receives RLF report [which may be of intra-RAT handover failure (e.g., ¶ [0028])]).
Regarding Claim 6, Liu discloses a method performed by a first network device, comprising: receiving a first report from a terminal device (e.g., ¶ [0114], an apparatus [receives] an RLF report… that includes information about one or more directional beams associated with the RLF event, and [identifies] that the RLF event is associated with a conditional handover failure based on receiving the RLF report), wherein the first report comprises a container that comprises at least one piece of information related to a handover failure (e.g., FIGS. 4, 8, ¶ [0282] [0315], UE may experience an RLF event with the target cell before the handover procedure is initiated or completed… UE may may transmit an RLF report including RLF information to the source cell), and the container uses a coding format corresponding to a wireless communication standard of a source network device (e.g., ¶ [0282] [0315], UE may transmit an RLF report including RLF information to the source cell [As reasoned in examination of claim 1, a report to a cell over an air interface is implied to be coded in the communication standard used by the cell, citing the prior art example, Xu, which discloses a UE, having determined a RLF related to a handover failure in a system where source and destination cell are different RATs (LTE and NR), generates an RLF report to send to the source cell, the report format being that of the source cell network standard (e.g., ¶ [0068], if the base station 1 is an LTE base station, the RLF report information is the “LTE RLF report”, which is in the format and encoding of the LTE RRC)]), the handover failure is a handover failure from the source network device to a target network device (e.g., ¶ [0010] [0028] [0054] [0306], RLF [determined, reported], RLF event [which] may be a… [inter-RAT] handover failure; e.g., FIG. 4, 8, ¶ [0282], UE 405 may experience an RLF event with the target cell 410 before the handover procedure is initiated or completed), and the source network device and the target network device are network devices using different communication standards (e.g., ¶ [0028] [0306], handover between different RATs (e.g., NR to LTE)) and processing the first report (e.g., ¶ [0113], receiving an RLF report from the UE… identifying that the RLF event is associated with [e.g., a conditional handover failure based on receiving the RLF report]).
Liu does not expressly disclose the container uses a coding format corresponding to a wireless communication standard of the source network device regardless of whether a first network device for receiving the first report is the source network device.
Rugeland discloses the container uses a coding format corresponding to a wireless communication standard of the source network device (e.g., ¶ [0146] Some embodiments disclosed herein provide multiple mechanisms at a UE and a network node for being able to indicate the UE identifier used in Reestablishment procedure in case of inter-RAT reestablishment procedures; ¶ [0147] Determining a set of parameters to be used as a UE identifier and to be included in a re-establishment request message to a second target RAT… The determination may be done upon detecting the failure e.g. radio link failure, handover failure, reconfiguration with sync failure or any other failure or ordinary triggering leading to a re-establishment and initiating reestablishment) regardless of whether the first network device is the source network device (e.g., ¶ [0153] Some second exemplifying embodiments. Create a new inter-RAT re-establishment request kind of message in each target RAT allowing source RAT parameters, e.g. the C-RNTI and the PCI, in the source RAT format to be transmitted in the second RAT during re-establishment without the need to perform further adjustments [The message in Rugeland is a re-establishment message sent after handover failure. Examiner interprets a re-establishment message as a “first report”; the UE may set the contents of the re-establishment message (e.g., ¶ [0064]) with failure information (e.g., ¶ [0073] [0074]), which Examiner interprets to be a report]; e.g., ¶ [0200] In some embodiments, the wireless device creates and/or uses a new variable or extending an existing variable to comprise the one or more parameters of the first set of parameters in both the format of the first RAT and in the format of the second RAT. The new variable may comprise parameters of only one format as in the legacy scenario or parameters of two or more formats according to embodiments disclosed herein [i.e., Examiner interprets this passage as more closely suggesting that the coding format may be if the first RAT even if the first network device is not the source]).
It would have been obvious to one of ordinary skill in the art at the time of the filing date to combine the disclosure of determining a handover failure on the target network device, as disclosed by Liu, with the disclosure of a coding format corresponding to a wireless communication standard of the source network device regardless of whether a first network device for receiving the first report is the source network device, as disclosed by Rugeland. The motivation to combine would have been to support multi-antenna techniques to increase data rates and reliability of a wireless communication system (Rugeland: e.g., ¶ [0003]).
Regarding Claim 7, Liu in view of Rugeland discloses all the limitations of the method according to claim 6.
Liu discloses wherein the processing the first report comprises: obtaining the container in the first report; and sending a second report to the source network device, wherein the second report comprises the container (e.g., ¶ [0113], transmitting a message to another cell of a network based on receiving the RLF report, the message including at least a portion of the information about the one or more directional beams associated with the RLF event and information about the conditional handover failure).
Regarding Claim 8, Liu in view of Rugeland discloses all the limitations of the method according to claim 7.
Liu discloses wherein the first report further comprises first information, and the first information comprises information that the first report is a report for an inter-RAT handover scenario, or wherein the second report further comprises third information, and the third information comprises information that the second report is for the inter-RAT handover scenario ([Examiner is treating the limitations recited in the alternative regarding a first or second report as one combined recited element, to establish that Liu discloses a report for an inter-RAT handover scenario]: e.g., ¶ [0054], RLF report may be configured to indicate … a handover failure; e.g., ¶ [0083], identifying whether a type of a handover may be an inter-RAT handover).
Regarding Claim 9, Liu in view of Rugeland discloses all the limitations of the method according to claim 7.
Liu discloses wherein the first report further comprises second information, and the second information comprises information that the first report is for an inter-RAT handover scenario or for an intra-system handover scenario, or wherein the second report further comprises fourth information, and the fourth information comprises information that the second report is for the inter-system handover scenario or for an intra-system handover scenario ([Examiner is treating the limitations recited in the alternative regarding a first or second report as one combined recited element, to establish that Liu discloses a report for an inter-RAT or intra-RAT handover scenario]: e.g., ¶ [0028] [0083] [0147], [identify] whether a type of a handover may be an inter-RAT handover or an intra-RAT handover, where the RLF report includes an indication of the type of the handover)).
Regarding Claim 10, Liu in view of Rugeland discloses all the limitations of the method according to claim 6.
Liu discloses further comprising: receiving first indication information from the terminal device, wherein the first indication information comprises information that the terminal device records the first report (e.g., ¶ [0040], apparatus receives RLF report [which may be of inter-RAT handover failure (e.g., ¶ [0028])] RLF report from the UE); and sending second indication information from the first network device, wherein the second indication information comprises information the terminal device to report the first report (e.g., ¶ [0040], The apparatus may include further means for transmitting a message to another cell of a network based on receiving the RLF report, the message including at least a portion of the information about the one or more directional beams associated with the RLF event).
Regarding Claim 11, Liu in view of Rugeland discloses a communication apparatus (Liu: e.g., FIG. 15, device 1505), comprising: a memory storing a program (Liu: e.g., FIG. 15, memory 1530), a processor coupled to the memory, the program comprising instructions (Liu: e.g., FIG. 15, processor 1540; ¶ [0383], memory 1530 may include random access memory (RAM) and read-only memory (ROM). The memory 1530 may store computer-readable, computer-executable code 1535 including instructions that, when executed, cause the processor to perform various functions described herein [also see, ¶ [0385]]) that when executed by the processor cause the processor to perform operations that are functionally similar to those performed in the method of claim 1. Therefore, the reasoning used in the examination of claim 1 shall be applied to claim 11.
Regarding Claim 12, Liu in view of Rugeland discloses all the limitations of the apparatus according to claim 11.
The functional limitations of Claim 12 are similar to claim 2. Therefore, the reasoning used in the examination of claim 2 shall be applied to claim 12.
Regarding Claim 13, Liu in view of Rugeland discloses all the limitations of the apparatus according to claim 11.
The functional limitations of Claim 13 are similar to claim 3. Therefore, the reasoning used in the examination of claim 3 shall be applied to claim 13.
Regarding Claim 14, Liu in view of Rugeland discloses all the limitations of the apparatus according to claim 11.
The functional limitations of Claim 14 are similar to claim 4. Therefore, the reasoning used in the examination of claim 4 shall be applied to claim 14.
Regarding Claim 16, Liu in view of Johannson discloses all the limitations of the apparatus according to claim 15.
Liu discloses wherein the apparatus is the chip configured in the terminal device (e.g., ¶ [0384], The processor 1540 may include an intelligent hardware device, (e.g., an ASIC, an FPGA, a programmable logic device, a discrete gate or transistor logic component, a discrete hardware component, or any combination thereof)… to cause the device 1505 to perform various functions (e.g., functions or tasks supporting techniques for communicating mobility information); e.g., ¶ [0601], The various illustrative blocks and modules described in connection with the disclosure herein may be implemented or performed with… an ASIC).
Regarding Claim 17, Liu in view of Rugeland discloses all the limitations of the apparatus according to claim 15.
Liu discloses wherein the apparatus is the terminal device (e.g., FIG. 15, device 1505).
Regarding Claim 19, Liu in view of Rugeland discloses all the limitations of the method according to claim 1.
Liu discloses wherein the first report further comprises a third container using a second coding format corresponding to a wireless communication standard of the first network device receiving the first report (e.g., ¶ [0282] [0315], UE may transmit an RLF report including RLF information to the source cell [Examiner asserts that a report to the source cell by UE over air interface to the cell is implied to be coded in the communication standard used by the source cell. Prior art example, Xu et al, U.S. Patent Application Publication No. 20210144610 A1 (hereinafter Xu, using the prior art date of related Chinese Patent Application Publication No. CN 112788693A) discloses a UE, having determined a RLF related to a handover failure in a system where source and destination cell may be different RATs (e.g., LTE and NR), generates an RLF report to send to a cell, the report format being that of the cell network standard. Particularly, Xu discloses a UE determining a handover related failure in a cell of a base station 1 (e.g., FIG. 3, ¶ [0052]), saving, among other details, the cell identity of the source cell that triggered the handover before failure (e.g. ¶ [0055]), cell identity where UE attempts to reestablish RRC connection after the failure (e.g., ¶ [0062]), and stores the RLF report of which radio access technology the stored RLF report information is, such as an LTE RLF report or an NR RLF report (e.g., ¶ [0064]). If, for example, the base station 1 is an LTE base station, the RLF report information is the “LTE RLF report”, which is in the format and encoding of the LTE RRC (e.g., ¶ [0068])]), the first network device is different from the source network device, and the second coding format is different from the coding format corresponding to the wireless communication standard of the source network device (Examiner again interprets that the two RAT in inter-RAT handover would have different coding format from each other).
Regarding Claim 20, Liu in view of Rugeland discloses all the limitations of the method according to claim 1.
Liu discloses wherein the at least one piece of information in the container indicates at least one of: a failed cell, a failure type, a source cell, a reestablishment cell, a cell radio network temporary identifier (C-RNTI), timing information, or signal quality measurements (e.g., ¶ [0253], The RLF report may include one or more radio measurements, such as a C-RNTI of the master node and/or the secondary node, a cell identity, an indication of a cause of the RLF, time information, location information, the UE RLF report container, an indication of a beam, a service interruption time, a conditional handover failure report, another report, or a combination thereof. In some examples, the radio measurements may include a signal strength (e.g., an RSRP or a RSRQ) of the last serving cell, including an MCG and an SCG measurement; a signal strength, a frequency, and an identity of a neighboring cell as configured by the master node and/or the secondary node; other radio measurements; or a combination thereof. In some examples, the cell identity may include a cell identity of the failed cell, including an identity of the associated master node and/or the associated secondary node; an identity of a previous primary cell (PCell), where the previous PCell may be a source PCell when a last RRC reconfiguration message and a last mobility control information was received; an identity of a previous primary secondary cell (PSCell), where the previous PSCell may be a source PSCell when the last RRC reconfiguration message and the last mobility control information was received; an identity of a reestablishment cell, where the reestablishment cell may be a cell in which a reestablishment attempt was made after the connection failure; another cell identity; or a combination thereof. In some examples, the indication of the cause of the RLF may indicate the RLF was caused by a handover failure, a beam recovery failure (BRF), etc. In some examples, the time information may include an indication of a time elapsed between an initialization of the handover and the connection failure, an indication of a time elapsed between the connection failure and a delivery of the RLF report, etc. In some examples, the indication of the beam may include a beam identifier, a beam measurement, etc. In some examples, the conditional handover failure report may include a candidate cell list, a list of cells attempted after the RLF, an attempted number after the RLF, etc).
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. References considered relevant to this application are listed in the attached "Notice of References Cited” (PTO-892).
Any inquiry concerning this communication or earlier communications from the examiner should be directed to VLADISLAV Y AGUREYEV whose telephone number is (571)272-0549. The examiner can normally be reached Monday--Friday (9-5).
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, Sujoy Kundu, can be reached on (571) 272-8586. 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.
/VLADISLAV Y AGUREYEV/Examiner, Art Unit 2471
/SUJOY K KUNDU/Supervisory Patent Examiner, Art Unit 2471
Prosecution Insights