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 .
Response to Amendment
Applicant’s submission filed 07/21/2026 has been entered. Claims 1, 3, 5, 12, 14, and 16 are amended. Claims 21-30 are new. Claims 6-11 and 17-20 are canceled. Claims 1-5, 12-16, and 21-30 are pending.
Response to Arguments
Applicant's arguments filed 07/21/2026 have been fully considered but they are not persuasive.
Applicant argues, pg. 8, neither Zaus nor Kim et al. (US 2023/0053805), Kim’805 teaches or suggests:
ACR scenario request information comprising an AC identifier and requesting the EES to allocate an ACR scenario to the EEC for the AC identified by the identifier
Selection and allocation, to the EEC for the identified AC, of an ACR scenario
ACR mode information comprising a correspondence between the AC identifier and the ACR scenario allocated to the EEC for that AC
Applicant argues, pg. 9, that Zaus does not disclose that the EEC send a request expressly requesting the EES to allocate an ACR scenario to the EEC for an AC identified by an AC identifier.
Zaus teaches the ACR scenario request information [0085], requesting the EES to allocate an ACR scenario to the EEC [0085], selection and allocation, to the EEC, of an ACR scenario [0060].
Applicant further argues, pg. 9, that Zaus does not teach that the EES returns a correspondence binding that identified AC to an ACR scenario actually allocated to the EEC.
The ACR mode information comprising a correspondence between the AC and the allocated ACR is implied by necessity in Zaus [0060-0061], and Zaus [0076] teaches an AC profile, but is silent concerning an AC identifier included in the profile.
However, the newly applied Kim et al. (US 2021/0058489), Kim’489, teaches using an application ID in an ACR request [0157-0158].
Arguments regarding Kim’805 are moot as the reference is no longer applied.
Claim Objections
Claims 1, 12, 14 is objected to for minor in formalities.
Claim 1, lines 15-17, and claim 12, lines 17-19, recite “… and the ACR capability information supported by the EES the AC.” Based on the other limitation of the clause, for the purpose of examination, the claim is examined as reciting “… and the ACR capability information supported by the EES;”
Claim 14, line 3, recites “send the ACR mode information the EAS” which should recite “send the ACR mode information to the EAS” as is consistent with the corresponding method of claim 2.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 1-5, 12-16, and 21-30 are rejected under 35 U.S.C. 103 as being unpatentable over Zaus et al. (US2022/0321673), Zaus hereinafter, in view of Kim et al. (US 2021/0058489), Kim’489 hereinafter.
Re. Claim 1. Zaus teaches a method (Zaus, 0012: In one aspect, the exemplary embodiments introduce mechanisms to determine a method for ACR that is supported by the UE and network entities involved in the ACR.), comprising:
receiving, by an edge enabler server (EES) from an edge enabler client (EEC), application context relocation (ACR) scenario request information comprising In a fifth example, an edge enabler server (EES) of an edge data network (EDN) is configured to perform operations comprising receiving, from one or more edge application servers (EAS), a first message indicating whether each EAS supports service continuity and one or more application context relocation (ACR) methods supported by each of the EASs that support service continuity and receiving, from an edge enabler client (EEC) of a user equipment (UE), a second message indicating that an application client (AC) of the UE requesting service from the EDN requires service continuity support from the EDN, one or more ACR methods supported by the AC and one or more ACR methods supported by the EEC.),
wherein the ACR scenario request information requests the EES to allocate an ACR scenario to the EEC for the AC identified by In a fifth example, an edge enabler server (EES) of an edge data network (EDN) is configured to perform operations comprising receiving, from one or more edge application servers (EAS), a first message indicating whether each EAS supports service continuity and one or more application context relocation (ACR) methods supported by each of the EASs that support service continuity and receiving, from an edge enabler client (EEC) of a user equipment (UE), a second message indicating that an application client (AC) of the UE requesting service from the EDN requires service continuity support from the EDN, one or more ACR methods supported by the AC and one or more ACR methods supported by the EEC.);
obtaining, by the EES, ACR capability information supported by an edge application server (EAS) (Zaus [0051] During the registration procedure, the EAS 172 may send an EAS profile information element (IE) to the EES 174. The EAS profile IE may include the service continuity supported indication referenced above. In addition, the EAS 172 may indicate which ACR methods are supported by the EAS 172.),
ACR capability information supported by the EEC (Zaus [0056] During either EEC registration or EAS discovery, the EEC 240 may send a service continuity supported indication to the EES 174 in an application client profile IE. In addition, the EEC 240 may also signal which ACR methods are supported by the AC 235 and which ACR methods are supported by the EEC 240.),
ACR capability information supported by the AC (Zaus [0050] In 405, the AC 235 sends a message to the EEC 240 indicating which ACR methods are supported by the AC 235.), and
ACR capability information supported by the EES (Zaus [0086] In a sixth example, the EES of the fifth example, wherein the operations further comprise transmitting, to an edge configuration server (ECS), a third message comprising whether the EES supports service continuity and one or more ACR methods supported by the EES.
[0087] In a seventh example, the EES of the sixth example, wherein the third message includes an EES profile.
[In sending the third message comprising the ACR methods supported by the EES to an ECS, it is implicit that the EES obtained the ACR capability information supported by the EES.]);
selecting and allocating, to the EEC for the AC identified by
the ACR scenario from ACR scenarios supported by the AC, the EEC, the EAS, and the EES based on the ACR capability information supported by the EAS, the ACR capability information supported by the EEC, the ACR capability information supported by the AC, and the ACR capability information supported by the EES [The exemplary embodiments introduce mechanisms that enable the entities involved in an ACR procedure (e.g., AC, EEC, s-EAS, s-EES, t-EAS, t-EES, etc.) to indicate their capabilities related to ACR to the other entities so that when an ACR procedure is triggered by one of the entities, the EEC or s-EES may determine whether all the other entities to be involved in the ACR procedure support a specific ACR method. The capability information may be used during EES selection and EAS discovery to initially select serving entities and then select target entities that support an ACR method that matches the capabilities of the AC/EEC of the UE 110.); and
sending, to the EEC, ACR mode information comprising a correspondence between the AC and the ACR scenario allocated to the EEC for the AC (Zaus [0059] In accordance with other ACR methods (e.g., method 1, 2, 5), the EEC 240 of the UE 110 may perform a discovery procedure to locate one or more potential t-EASs. This discovery procedure may be performed with the currently serving EES or a potential target EES to determine which EASs and/or EESs match the supported ACR methods of the AC 235, the EEC 240, s-EES 174 and s-EAS 172. In some embodiments, the EES 174 may inform the EEC 240 of only the common ACR methods where the AC 235 or EEC 240 initiates the ACR signaling procedure (e.g., method 1, 2, 5).
[0060] The EES may then inform the requesting entity about the common ACR methods in the EAS discovery response message.
[0061] For instance, on the UE 110 side, there may be multiple different ACs using the same EEC 240. On the network side, multiple EASs may be registered to a single EES. Thus, the EEC 240 may attempt to discover EASs for each of the ACs. If the EASs are registered to the same EES, a scenario may occur where multiple EASs that support ACR methods common to the other entities may be discovered using a single EAS discovery procedure. Otherwise, if at least one common ACR method is not identified by the network or the EEC 240 identifies that the ACs do not support a same ACR method, a separate EAS discovery procedure may be performed for each of the ACs. Alternatively, the at least one common ACR method identified by the network for a first AC may be different from the at least one common ACR method identified as a second AC and the UE 110 and the network may use different ACR methods for different ACs when the need for an ACR is determined.
[While a correspondence between an identified AC and an ACR scenario/method is not explicitly mentioned, in order for the UE and the network to functionally use different ACR methods for different ACs of the same EEC, it is necessary that there is an indication of which ACR method is used for which AC; an indication of a correspondence between the AC and the ACR method/scenario is implicit for operability.]).
Yet Zaus does not explicitly teach that receiving, by an edge enabler server (EES) from an edge enabler client (EEC), application context relocation (ACR) scenario request information comprising an identifier of an application client (AC),
wherein the ACR scenario request information requests the EES to allocate an ACR scenario to the EEC for the AC identified by the identifier;
selecting and allocating, to the EEC for the AC identified by the identifier,
sending, to the EEC, ACR mode information comprising a correspondence between the identifier of the AC and the ACR scenario allocated to the EEC for the AC.
[For clarity, Zaus [0076] teaches an AC profile, but is silent concerning an AC identifier included in the profile.]
However, in the related art, Kim’489 teaches receiving, by an edge enabler server (EES) from an edge enabler client (EEC), application context relocation (ACR) scenario request information comprising an identifier of an application client (AC) (Kim’489 Fig. 4: 404; [0156] According to various embodiments, the EEC 52 of the user device 50 may transmit a request for relocating application context to the S-EES 100.
[0157] The EEC 52 may transmit the request for relocating the application context to the determined S-EES 100, and the corresponding request may include the following information.
[0158] (1) Application information (for example, application ID) may be included.),
wherein the ACR scenario request information requests the EES to allocate an ACR scenario to the EEC for the AC identified by the identifier (Kim’489 Fig. 4: 404; [0156] According to various embodiments, the EEC 52 of the user device 50 may transmit a request for relocating application context to the S-EES 100.
[0157] The EEC 52 may transmit the request for relocating the application context to the determined S-EES 100, and the corresponding request may include the following information.
[0158] (1) Application information (for example, application ID) may be included.);
selecting and allocating, to the EEC for the AC identified by the identifier (Kim’489 Fig. 4: 420; [0189] According to various embodiments, the S-EES 100 may transmit the application context relocation response to the EEC 52 of the user device 50 at step 420.),
sending, to the EEC, ACR mode information comprising a correspondence between the identifier of the AC and the ACR scenario allocated to the EEC for the AC (Kim’489 [0157] The EEC 52 may transmit the request for relocating the application context to the determined S-EES 100, and the corresponding request may include the following information.
[0158] (1) Application information (for example, application ID) may be included.).
Therefore, it would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to combine the invention of Zaus with the inclusion of an application ID in the request for relocating the application context. The resulting invention would provide for continuous service when a mobile terminal is changing due to movement (Kim’489 [0004]).
Re. Claim 2. Zaus and Kim’489 teach claim 1.
Zaus further teaches wherein the method is performed by the EES or a chip of the EES (Zaus, 0085: In a fifth example, an edge enabler server (EES) of an edge data network (EDN) is configured to perform operations comprising receiving, from one or more edge application servers (EAS), a first message indicating whether each EAS supports service continuity and one or more application context relocation (ACR) methods supported by each of the EASs that support service continuity and receiving, from an edge enabler client (EEC) of a user equipment (UE), a second message indicating that an application client (AC) of the UE requesting service from the EDN requires service continuity support from the EDN, one or more ACR methods supported by the AC and one or more ACR methods supported by the EEC.).
Re. Claim 3. Zaus in view of Kim’489 claim 2.
Yet Zaus does not explicitly teach sending the ACR mode information to the EAS.
However, in the related art, Kim’489 teaches sending the ACR mode information to the EAS (Kim’489 Fig. 4: 406; [0166] According to an embodiment, the S-EES 100 may provide UE information to the S-EAS 101 to specify application context for the corresponding UE required to be relocated. The S-EES 100 may perform step 406 by providing an application ID.).
Re. Claim 4. Zaus and Kim’489 teach claim 2.
Zaus further teaches wherein the obtaining the ACR capability information supported by the EAS comprises: receiving, from the EAS, the ACR capability information supported by the EAS (Zaus, 0085: In a fifth example, an edge enabler server (EES) of an edge data network (EDN) is configured to perform operations comprising receiving, from one or more edge application servers (EAS), a first message indicating whether each EAS supports service continuity and one or more application context relocation (ACR) methods supported by each of the EASs that support service continuity and receiving, from an edge enabler client (EEC) of a user equipment (UE), a second message indicating that an application client (AC) of the UE requesting service from the EDN requires service continuity support from the EDN, one or more ACR methods supported by the AC and one or more ACR methods supported by the EEC.).
Re. Claim 5. Zaus in view of Kim’489 teaches claim 2,
Zaus further teaches wherein the obtaining the ACR capability information supported by the EEC and the ACR capability information supported by the AC comprises:
receiving, from the EEC, the ACR capability information supported by the EEC and an AC profile comprising the ACR capability information supported by the AC (Zaus [0085] In a fifth example, an edge enabler server (EES) of an edge data network (EDN) is configured to perform operations comprising receiving, from one or more edge application servers (EAS), a first message indicating whether each EAS supports service continuity and one or more application context relocation (ACR) methods supported by each of the EASs that support service continuity and receiving, from an edge enabler client (EEC) of a user equipment (UE), a second message indicating that an application client (AC) of the UE requesting service from the EDN requires service continuity support from the EDN, one or more ACR methods supported by the AC and one or more ACR methods supported by the EEC.).
Re. Claim 12. Zaus teaches an apparatus (Zaus, 0021: In addition to an EAS, an ACR procedure may involve an AC of the UE, an edge enabler client (EEC) of the UE, a source edge enabler server (s-EES), a s-EAS, a target EES (t-EES) and a t-EAS.), comprising:
at least one processor (Zaus, 0038: The edge data network 170 may also include an edge enabler server (EES).
[A processor is a necessary component of a server.]); and
one or more memories coupled to the at least one processor and storing programming instructions that, when executed by the at least one processor (Zaus, 0038: The edge data network 170 may also include an edge enabler server (EES).
[Memory is a necessary component of a server.]).
Further elements of Claim 12 correspond to the method of claim 1. Claim 12 does not define or further limit over the subject matter of claim 1. Therefore, claim 12 is rejected for reasons similar to those laid out with respect to claim 1.
Re. Claim 13. Claim 13 correspond to the method of claim 2. Claim 13 does not define or further limit over the subject matter of claim 2. Therefore, claim 13 is rejected for reasons similar to those laid out with respect to claim 2.
Re. Claim 14. Claim 14 correspond to the method of claim 3. Claim 14 does not define or further limit over the subject matter of claim 3. Therefore, claim 14 is rejected for reasons similar to those laid out with respect to claim 3.
Re. Claim 15. Claim 15 correspond to the method of claim 4. Claim 15 does not define or further limit over the subject matter of claim 4. Therefore, claim 15 is rejected for reasons similar to those laid out with respect to claim 4.
Re. Claim 16. Claim 16 correspond to the method of claim 5. Claim 16 does not define or further limit over the subject matter of claim 5. Therefore, claim 16 is rejected for reasons similar to those laid out with respect to claim 5.
Re. Claim 21. Zaus teaches an apparatus (Zaus [0029] FIG. 2 shows an exemplary UE 110 according to various exemplary embodiments.), comprising:
at least one processor (Zaus [0029] The UE 110 may include a processor 205, a memory arrangement 210, a display device 215, an input/output (I/O) device 220, a transceiver 225 and other components 230.); and
one or more memories coupled to the at least one processor and storing programming instructions that, when executed by the at least one processor (Zaus [0030] The processor 205 may be configured to execute various types of software. For example, the processor may execute an application client (AC) 235 and an edge enabler client (EEC) 240.), cause the apparatus to:
send, to an edge enabler server (EES), application context relocation (ACR) scenario request information comprising The processor 205 may be configured to execute various types of software. For example, the processor may execute an application client (AC) 235 and an edge enabler client (EEC) 240.
[0063] When the EEC 240 signals to the EES during EEC registration or EAS discovery (e.g., 425) or when the EEC signals to the ECS 180 during service provisioning (e.g., 420), the EEC 240 may provide a service continuity supported indication and indicate which ACR methods are supported by the AC 235 and the EEC 240.),
wherein THE ACR scenario request information requests the EES to allocate an ACR scenario to an edge enabler client (EEC) for the AC identified by When the EEC 240 signals to the EES during EEC registration or EAS discovery (e.g., 425) or when the EEC signals to the ECS 180 during service provisioning (e.g., 420), the EEC 240 may provide a service continuity supported indication and indicate which ACR methods are supported by the AC 235 and the EEC 240.);
send, to the EES, ACR capability information supported by the AC and ACR capability information supported by the EEC (Zaus [0063] When the EEC 240 signals to the EES during EEC registration or EAS discovery (e.g., 425) or when the EEC signals to the ECS 180 during service provisioning (e.g., 420), the EEC 240 may provide a service continuity supported indication and indicate which ACR methods are supported by the AC 235 and the EEC 240.); and
receive, from the EES, ACR mode information comprising a correspondence between the AC and the ACR scenario allocated to the EEC for the AC (Zaus [0060] The EES may then inform the requesting entity about the common ACR methods in the EAS discovery response message.
[0061] For instance, on the UE 110 side, there may be multiple different ACs using the same EEC 240. On the network side, multiple EASs may be registered to a single EES. Thus, the EEC 240 may attempt to discover EASs for each of the ACs. If the EASs are registered to the same EES, a scenario may occur where multiple EASs that support ACR methods common to the other entities may be discovered using a single EAS discovery procedure. Otherwise, if at least one common ACR method is not identified by the network or the EEC 240 identifies that the ACs do not support a same ACR method, a separate EAS discovery procedure may be performed for each of the ACs. Alternatively, the at least one common ACR method identified by the network for a first AC may be different from the at least one common ACR method identified as a second AC and the UE 110 and the network may use different ACR methods for different ACs when the need for an ACR is determined.
[While a correspondence between an identified AC and an ACR scenario/method is not explicitly mentioned, in order for the UE and the network to functionally use different ACR methods for different ACs of the same EEC, it is necessary that there is an indication of which ACR method is used for which AC; an indication of a correspondence between the AC and the ACR method/scenario is implicit for operability.]),
wherein the ACR scenario is selected and allocated by the EES from ACR scenarios supported by the AC, the EEC, an edge application server (EAS), and the EES (Zaus [0060] The EES may consider a supported ACR methods indication matching, if it has at least one supported ACR methods in common with the other entities (e.g., AC 235, EEC 240 and s-EES 174 for the case of EAS discovery or AC 235, EEC 240, s-EES 174 and s-EAS 172 for the case of t-EAS discovery). The EES may then attempt to find at least one ACR method common to the other entities. The EES may then inform the requesting entity about the common ACR methods in the EAS discovery response message.
[In finding a common ACR method to all entities, the ACR method is necessarily determined by the capability information of the AC, the EEC, the EAS, and the EES.]);
wherein the apparatus is the EEC or a chip of the EEC (Zaus [0056] In 425, the EEC 240 performs EEC registration and EAS discovery with the EES 174. During either EEC registration or EAS discovery, the EEC 240 may send a service continuity supported indication to the EES 174 in an application client profile IE. In addition, the EEC 240 may also signal which ACR methods are supported by the AC 235 and which ACR methods are supported by the EEC 240.).
Yet, Zaus does not explicitly teach send, to an edge enabler server (EES), application context relocation (ACR) scenario request information comprising an identifier of an application client (AC),
wherein THE ACR scenario request information requests the EES to allocate an ACR scenario to an edge enabler client (EEC) for the AC identified by the identifier;
receive, from the EES, ACR mode information comprising a correspondence between the identifier of the AC and the ACR scenario allocated to the EEC for the AC.
[For clarity, Zaus [0076] teaches an AC profile, but is silent concerning an AC identifier included in the profile.]
However, in the related art, Kim’489 teaches send, to an edge enabler server (EES), application context relocation (ACR) scenario request information comprising an identifier of an application client (AC) (Kim’489 Fig. 4: 404; [0156] According to various embodiments, the EEC 52 of the user device 50 may transmit a request for relocating application context to the S-EES 100.
[0157] The EEC 52 may transmit the request for relocating the application context to the determined S-EES 100, and the corresponding request may include the following information.
[0158] (1) Application information (for example, application ID) may be included.),
wherein THE ACR scenario request information requests the EES to allocate an ACR scenario to an edge enabler client (EEC) for the AC identified by the identifier (Kim’489 Fig. 4: 404; [0156] According to various embodiments, the EEC 52 of the user device 50 may transmit a request for relocating application context to the S-EES 100.
[0157] The EEC 52 may transmit the request for relocating the application context to the determined S-EES 100, and the corresponding request may include the following information.
[0158] (1) Application information (for example, application ID) may be included.);
receive, from the EES, ACR mode information comprising a correspondence between the identifier of the AC and the ACR scenario allocated to the EEC for the AC (Kim’489 [0157] The EEC 52 may transmit the request for relocating the application context to the determined S-EES 100, and the corresponding request may include the following information.
[0158] (1) Application information (for example, application ID) may be included.).
Therefore, it would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to combine the invention of Zaus with the inclusion of an application ID in the request for relocating the application context. The resulting invention would provide for continuous service when a mobile terminal is changing due to movement (Kim’489 [0004]).
Re. Claim 22. Zaus in view of Kim’489 teaches claim 21,
wherein the apparatus is further caused to send the ACR mode information to the AC (Zaus [0063] When the EEC 240 signals to the EES during EEC registration or EAS discovery (e.g., 425) or when the EEC signals to the ECS 180 during service provisioning (e.g., 420), the EEC 240 may provide a service continuity supported indication and indicate which ACR methods are supported by the AC 235 and the EEC 240.).
Re. Claim 23 Zaus in view of Kim’489 teaches claim 21,
wherein the ACR scenario request information, the identifier of the AC, the ACR capability information supported by the AC, and the ACR capability information supported by the EEC are carried in a single request message (Zaus [0056] In 425, the EEC 240 performs EEC registration and EAS discovery with the EES 174. During either EEC registration or EAS discovery, the EEC 240 may send a service continuity supported indication to the EES 174 in an application client profile IE. In addition, the EEC 240 may also signal which ACR methods are supported by the AC 235 and which ACR methods are supported by the EEC 240.
Kim’489 [0157] The EEC 52 may transmit the request for relocating the application context to the determined S-EES 100, and the corresponding request may include the following information.
[0158] (1) Application information (for example, application ID) may be included.).
Re. Claim 24. Zaus in view of Kim’489 teaches claim 23,
wherein the ACR mode information is carried in a response message corresponding to the request message (Zaus [0060] The EES may then inform the requesting entity about the common ACR methods in the EAS discovery response message.).
Re. Claim 25. Claim 25 is directed toward a method corresponding to the apparatus of claim 21. Claim 25 does not define or further limit over the subject matter of claim 21. Therefore, claim 25 is rejected for reasons similar to those laid out with respect to claim 21.
Re. Claim 26. Claim 26 is directed toward a method corresponding to the apparatus of claim 22. Claim 26 does not define or further limit over the subject matter of claim 22. Therefore, claim 26 is rejected for reasons similar to those laid out with respect to claim 22.
Re. Claim 27. Claim 27 is directed toward a method corresponding to the apparatus of claim 23. Claim 27 does not define or further limit over the subject matter of claim 23. Therefore, claim 27 is rejected for reasons similar to those laid out with respect to claim 23.
Re. Claim 28. Claim 28 is directed toward a method corresponding to the apparatus of claim 24. Claim 28 does not define or further limit over the subject matter of claim 24. Therefore, claim 28 is rejected for reasons similar to those laid out with respect to claim 24.
Allowable Subject Matter
Claims 29 and 30 are objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims.
Conclusion
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.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to CASON H MORSE whose telephone number is (571)270-5235. The examiner can normally be reached 8:30-6:00 Mon.-Thurs., Fri. varies.
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, Rebecca Song can be reached at (571) 270-3667. 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.
/C.H.M./ Examiner, Art Unit 2417
/REBECCA E SONG/ Supervisory Patent Examiner, Art Unit 2417
