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 .
This Office Action is in response to the Applicant Arguments/REMARKS correspondence 08/13/2025.
Claims 1-14 are pending and rejected.
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 08/13/2025 has been entered.
Response to Arguments
Applicant’s arguments with respect to claims 1-14 have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
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.
Claims 1-14 are rejected under 35 U.S.C. 103 as being unpatentable over 3GPP TS 23.503 (2021-01) (hereinafter "Spec-1"), in further view of 3GPP TS 24.526 (2021-04) (hereinafter "Spec-2") in further view of 3GPP TS 23.501 (2020-10) (hereinafter “Spec-3”).
Regarding claim 1, Spec-1 teaches a method, comprising:
initiating a Route Selection Policy (URSP) rule matching procedure by a User Equipment (UE) in a mobile communication network, wherein the UE selects a URSP rule from one or more URSP rules (Section 6.6.2.3 pg. 74 paragraph 1 “for every newly detected application the UE evaluates the URSP rules in order of Rule Precedence and determines if the application is matching the Traffic descriptor of any URSP rule”—directly teaches that the UE initiates URSP rule matching and evaluates URSP rules in order (selects an applicable URSP rule));
matching a traffic descriptor of the selected URSP rule with an application information (Section 6.6.2.3, pg. 74 “determines if the application is matching the traffic descriptor of any URSP rule”, exact language, UE checks whether the application matches the Traffic descriptor);
selecting and evaluating a route selection descriptor (RSD) from a list of RSDs of the selected URSP rule to be matched with a PDU session (Section 6.6.2.3 pg 74-75, “the UE shall select a Route Selection Descriptor within this URSP rule in the order of the Route Selection Descriptor Precedence; When a valid Route Selection descriptor is found, the UE determines if there is an existing PDU Session that matches all components in the selected Route Selection Descriptor”—First phrase supports selecting an RSD from the list (in precedence order); Second phrase supports evaluating the selected RSD by checking whether an existing PDU session matches the RSD components),
But Spec-1 fails to teach wherein the RSD has a list of stored RSD components for a redundant PDU session comprising a PDU session pair ID or a redundancy sequency number (RSN); and
ignoring the RSD upon determining that the RSD further comprises a preferred access type set to non-3GPP access, or ignores the RSD upon determining that the RSD further comprises a multi-access preference type.
However, Spec-2 teaches wherein the RSD has a list of stored RSD components for a redundant PDU session comprising a PDU session pair ID or a redundancy sequency number (RSN) (Section 4.2.1 pg. 8, “one PDU session type and, optionally, one or more of the following: E) preferred access type; F) multi-access preference; G) a time window and H) location criteria;” shows that the RSD can include PDU session pair ID and RSN as stored components); and
ignoring the RSD upon determining that the RSD further comprises a preferred access type set to non-3GPP access, or ignores the RSD upon determining that the RSD further comprises a multi-access preference type (pg. 28 Note 2, ignoring & Section 4.2.2.2 pg 9-11, multi-access preference[Wingdings font/0xE0] “v) the selected descriptor includes the multi-access preference but the UE does not support ATSSS, the UE shall proceed to step 4);”; On preferred access type/multi-access generally[Wingdings font/0xE0] “E) preferred access type or multi-access preference, if the preferred access type or the multi-access preference is in the route selection descriptor; and” On recommended behavior when included[Wingdings font/0xE0] “Note 6: if a preferred access type or a multi-access preference is included in the traffic descriptor of a URSP rule, it is recommended that the UE establishes a PDU session based on the preferred access type or the multi-access preference.”; explicit handling logic—if an RSD includes a multi-access preference that the UE cannot support, the UE proceeds to step 4; which means to skip this RSD and move on to the next (ignore)).
Spec-1 discloses the overall URSP evaluation method: the UE evaluates URSP rules in order, matches traffic descriptors to application information, selects/evaluates RSDs, and considers them valid only if access type preference, multi-access preference, or other validity conditions are met. Spec-2 explicitly enumerates the RSD component set, including preferred access type, multi-access preference, PDU session pair ID, and RSN. It also specifies UE behavior when these conditions are not met, for example: “the selected route selection descriptor includes the multi-access preference but UE does not support ATSSS, UE shall proceed to step 4” (i.e. skip to the next RSD).
A POSITA would have been motivated to combine Spec-1, the explicit component set/handling rule of Spec-2 in order to align redundant session management with the broader 3GPP-defined route selection framework. The predictable result is a UE that evaluates RSDs containing PDU Session Pair ID/RSN along with other components (preferred access, multi-access preference) and ignores any RSD that contains unsupported components, thereby achieving reliable URSP-based routing. Such combination is obvious because it uses standardized 3GPP handling (Spec-1, Spec-2) ensuring compatibility with 5G multi-access and redundancy features.
However, Spec-3 remedies the gaps left by Spec-2 in regards to a redundant PDU session comprising a PDU session pair ID or a redundancy sequency number (RSN) (pg. 325 Section 5.33.2.1 –RSD present from NOTE 3: “duplicated traffic…is differentiated by two distinct traffic descriptors…matched to the Route Selection Descriptors of distinct USRP rules”; RSD used for redundant PDU sessions—“two redundant PDU sessions…duplicated traffic…matched to the Route Selection Descriptors of distinct USRP rules”; Contains PDU session Pair ID or RSN—“SMF…determine[s] the RSN which differentiates the PDU Sessions that are handled redundantly…the value of the RSN parameter indicates redundant user plane requirements…”).
Spec-1 discloses the overall URSP evaluation method: the UE evaluates URSP rules in order, matches traffic descriptors to application information, selects/evaluates RSDs, and considers them valid only if access type preference, multi-access preference, or other validity conditions are met. Spec-2 explicitly enumerates the RSD component set, including preferred access type, multi-access preference, PDU session pair ID, and RSN. It also specifies UE behavior when these conditions are not met, for example: “the selected route selection descriptor includes the multi-access preference but UE does not support ATSSS, UE shall proceed to step 4” (i.e. skip to the next RSD). Spec-3 discloses dual connectivity based end to end redundant user plane paths, specifically, RSD present, used for redundant PDU sessions and contains RSN.
A POSITA would have been motivated to combine Spec-1, the explicit component set/handling rule of Spec-2, and Spec-3’s dual connectivity based end to end redundant user plane paths, specifically, RSD present, used for redundant PDU sessions and contains RSN in order to align redundant session management with the broader 3GPP-defined route selection framework. The predictable result is a UE that evaluates RSDs containing PDU Session Pair ID/RSN along with other components (preferred access, multi-access preference) and ignores any RSD that contains unsupported components, thereby achieving reliable URSP-based routing. Such combination is obvious because it uses standardized 3GPP handling (Spec-1, Spec-2) to manage RSN (Spec-3), ensuring compatibility with 5G multi-access and redundancy features.
Regarding claim 8, Spec-1 teaches a User Equipment (UE), comprising:
an upper layer handling circuit that initiates a UE Route Selection Policy (URSP) rule matching procedure in a mobile communication network, wherein the UE selects a URSP rule from one or more URSP rules (Section 6.6.2.3 pg. 74 paragraph 1 “for every newly detected application the UE evaluates the URSP rules in order of Rule Precedence and determines if the application is matching the Traffic descriptor of any URSP rule”—directly teaches that the UE initiates URSP rule matching and evaluates URSP rules in order (selects an applicable URSP rule));
a Route Selection Policy (URSP) handling circuit that matches a traffic descriptor of the selected URSP rule with an application information (Section 6.6.2.3, pg. 74 “determines if the application is matching the traffic descriptor of any URSP rule”, exact language, UE checks whether the application matches the Traffic descriptor),
wherein the UE selects and evaluating a route selection descriptor (RSD) from a list of RSDs of the selected URSP rule to be matched with a PDU session (Section 6.6.2.3 pg 74-75, “the UE shall select a Route Selection Descriptor within this URSP rule in the order of the Route Selection Descriptor Precedence; When a valid Route Selection descriptor is found, the UE determines if there is an existing PDU Session that matches all components in the selected Route Selection Descriptor”—First phrase supports selecting an RSD from the list (in precedence order); Second phrase supports evaluating the selected RSD by checking whether an existing PDU session matches the RSD components); and
But Spec 1 fails to teach a control circuit that determines that the RSD has a list of stored RSD components for a redundant PDU session comprising a PDU session pair ID or a redundancy sequency number (RSN),
wherein the UE ignores the RSD upon determining that the RSD further comprises a preferred access type set to non- 3GPP access or upon determining that the RSD further comprises a multi-access preference type.
However, Spec-2 teaches a control circuit that determines that the RSD has a list of stored RSD components for a redundant PDU session comprising a PDU session pair ID or a redundancy sequency number (RSN) (Section 4.2.1 pg. 8, “one PDU session type and, optionally, one or more of the following: E) preferred access type; F) multi-access preference; G) a time window and H) location criteria;” shows that the RSD can include PDU session pair ID and RSN as stored components),
wherein the UE ignores the RSD upon determining that the RSD further comprises a preferred access type set to non- 3GPP access or upon determining that the RSD further comprises a multi-access preference type (pg. 28 Note 2, ignoring & Section 4.2.2.2 pg 9-11, multi-access preference[Wingdings font/0xE0] “v) the selected descriptor includes the multi-access preference but the UE does not support ATSSS, the UE shall proceed to step 4);”; On preferred access type/multi-access generally[Wingdings font/0xE0] “E) preferred access type or multi-access preference, if the preferred access type or the multi-access preference is in the route selection descriptor; and” On recommended behavior when included[Wingdings font/0xE0] “Note 6: if a preferred access type or a multi-access preference is included in the traffic descriptor of a URSP rule, it is recommended that the UE establishes a PDU session based on the preferred access type or the multi-access preference.”; explicit handling logic—if an RSD includes a multi-access preference that the UE cannot support, the UE proceeds to step 4; which means to skip this RSD and move on to the next (ignore)).
Spec-1 discloses the overall URSP evaluation method: the UE evaluates URSP rules in order, matches traffic descriptors to application information, selects/evaluates RSDs, and considers them valid only if access type preference, multi-access preference, or other validity conditions are met. Spec-2 explicitly enumerates the RSD component set, including preferred access type, multi-access preference, PDU session pair ID, and RSN. It also specifies UE behavior when these conditions are not met, for example: “the selected route selection descriptor includes the multi-access preference but UE does not support ATSSS, UE shall proceed to step 4” (i.e. skip to the next RSD).
A POSITA would have been motivated to combine Spec-1, the explicit component set/handling rule of Spec-2 in order to align redundant session management with the broader 3GPP-defined route selection framework. The predictable result is a UE that evaluates RSDs containing PDU Session Pair ID/RSN along with other components (preferred access, multi-access preference) and ignores any RSD that contains unsupported components, thereby achieving reliable URSP-based routing. Such combination is obvious because it uses standardized 3GPP handling (Spec-1, Spec-2) ensuring compatibility with 5G multi-access and redundancy features.
However, Spec-3 remedies the gaps left by Spec-2 in regards to a redundant PDU session comprising a PDU session pair ID or a redundancy sequency number (RSN) (pg. 325 Section 5.33.2.1 –RSD present from NOTE 3: “duplicated traffic…is differentiated by two distinct traffic descriptors…matched to the Route Selection Descriptors of distinct USRP rules”; RSD used for redundant PDU sessions—“two redundant PDU sessions…duplicated traffic…matched to the Route Selection Descriptors of distinct USRP rules”; Contains PDU session Pair ID or RSN—“SMF…determine[s] the RSN which differentiates the PDU Sessions that are handled redundantly…the value of the RSN parameter indicates redundant user plane requirements…”).
Spec-1 discloses the overall URSP evaluation method: the UE evaluates URSP rules in order, matches traffic descriptors to application information, selects/evaluates RSDs, and considers them valid only if access type preference, multi-access preference, or other validity conditions are met. Spec-2 explicitly enumerates the RSD component set, including preferred access type, multi-access preference, PDU session pair ID, and RSN. It also specifies UE behavior when these conditions are not met, for example: “the selected route selection descriptor includes the multi-access preference but UE does not support ATSSS, UE shall proceed to step 4” (i.e. skip to the next RSD). Spec-3 discloses dual connectivity based end to end redundant user plane paths, specifically, RSD present, used for redundant PDU sessions and contains RSN.
A POSITA would have been motivated to combine Spec-1, the explicit component set/handling rule of Spec-2, and Spec-3’s dual connectivity based end to end redundant user plane paths, specifically, RSD present, used for redundant PDU sessions and contains RSN in order to align redundant session management with the broader 3GPP-defined route selection framework. The predictable result is a UE that evaluates RSDs containing PDU Session Pair ID/RSN along with other components (preferred access, multi-access preference) and ignores any RSD that contains unsupported components, thereby achieving reliable URSP-based routing. Such combination is obvious because it uses standardized 3GPP handling (Spec-1, Spec-2) to manage RSN (Spec-3), ensuring compatibility with 5G multi-access and redundancy features.
Regarding claim 9 (and method claim 2), Spec-1 fails to teach the UE, wherein the URSP rule matching procedure is initiated by upper layers of the UE and is triggered due to need to send a PDU of an application.
However, Spec-2 teaches the UE, wherein the URSP rule matching procedure is initiated by upper layers of the UE and is triggered due to need to send a PDU of an application (Section 4.2.2.2 pg. 9, “When the upper layers request information of the PDU session via which to send a PDU of an application…the UE shall evaluate the URSP rules…”, discloses the trigger from the upper layers when sensing a PDU of an application”).
Spec-1 discloses the overall URSP evaluation method: the UE evaluates URSP rules in order, matches traffic descriptors to application information, selects/evaluates RSDs, and considers them valid only if access type preference, multi-access preference, or other validity conditions are met. Spec-2 explicitly enumerates the RSD component set, including preferred access type, multi-access preference, PDU session pair ID, and RSN. It also specifies UE behavior when these conditions are not met, for example: “the selected route selection descriptor includes the multi-access preference but UE does not support ATSSS, UE shall proceed to step 4” (i.e. skip to the next RSD). Spec-3 discloses dual connectivity based end to end redundant user plane paths, specifically, RSD present, used for redundant PDU sessions and contains RSN.
A POSITA would have been motivated to combine Spec-1, the explicit component set/handling rule of Spec-2, and Spec-3’s dual connectivity based end to end redundant user plane paths, specifically, RSD present, used for redundant PDU sessions and contains RSN in order to align redundant session management with the broader 3GPP-defined route selection framework. The predictable result is a UE that evaluates RSDs containing PDU Session Pair ID/RSN along with other components (preferred access, multi-access preference) and ignores any RSD that contains unsupported components, thereby achieving reliable URSP-based routing. Such combination is obvious because it uses standardized 3GPP handling (Spec-1, Spec-2) to manage RSN (Spec-3), ensuring compatibility with 5G multi-access and redundancy features.
Regarding claim 10 (and method claim 3), Spec-1 fails to teach the UE, wherein each URSP rule comprises a precedence value, a traffic descriptor, and a list of route selection descriptors.
However, Spec-2 teaches the UE, wherein each URSP rule comprises a precedence value, a traffic descriptor, and a list of route selection descriptors (Section 4.2.1(c), pg. 7-8, “one or more route selection descriptors each consisting of a precedence value of the route selection descriptor…Only one URSP rule in the URSP can be a default URSP rule…any non-default URSP rule shall have lower precedence value…if one or more DNNs are included in the traffic descriptor…”; URSP rule = precedence value + traffic descriptor + list of RSDs).
Spec-1 discloses the overall URSP evaluation method: the UE evaluates URSP rules in order, matches traffic descriptors to application information, selects/evaluates RSDs, and considers them valid only if access type preference, multi-access preference, or other validity conditions are met. Spec-2 explicitly enumerates the RSD component set, including preferred access type, multi-access preference, PDU session pair ID, and RSN. It also specifies UE behavior when these conditions are not met, for example: “the selected route selection descriptor includes the multi-access preference but UE does not support ATSSS, UE shall proceed to step 4” (i.e. skip to the next RSD). Spec-3 discloses dual connectivity based end to end redundant user plane paths, specifically, RSD present, used for redundant PDU sessions and contains RSN.
A POSITA would have been motivated to combine Spec-1, the explicit component set/handling rule of Spec-2, and Spec-3’s dual connectivity based end to end redundant user plane paths, specifically, RSD present, used for redundant PDU sessions and contains RSN in order to align redundant session management with the broader 3GPP-defined route selection framework. The predictable result is a UE that evaluates RSDs containing PDU Session Pair ID/RSN along with other components (preferred access, multi-access preference) and ignores any RSD that contains unsupported components, thereby achieving reliable URSP-based routing. Such combination is obvious because it uses standardized 3GPP handling (Spec-1, Spec-2) to manage RSN (Spec-3), ensuring compatibility with 5G multi-access and redundancy features.
Regarding claim 11 (and method claim 4), Spec-1 teaches the UE, wherein the traffic descriptor comprises at least one of application identifiers, IP tuples, non-IP descriptors, data network names, connection capabilities, and domain descriptors (Section 6.6.2.1 defines traffic descriptor fields including application identifier, IP flow descriptors, DNN, domain name descriptors—directly to application IDs, IP tuples, non-IP descriptors, DNNs, connection capabilities, domain descriptors).
Regarding claim 12 (and method claim 5), Spec-1 fails to teach the UE, wherein each RSD from the list of RSDs is associated with a precedence value indicating a priority for matching.
However, Spec-2 teaches the UE, wherein each RSD from the list of RSDs is associated with a precedence value indicating a priority for matching (Section 4.2.1(c) pg. 8, “one or more route selection descriptors each consisting of a precedence value of the route selection descriptor…”—discloses RSD precedence values).
Spec-1 discloses the overall URSP evaluation method: the UE evaluates URSP rules in order, matches traffic descriptors to application information, selects/evaluates RSDs, and considers them valid only if access type preference, multi-access preference, or other validity conditions are met. Spec-2 explicitly enumerates the RSD component set, including preferred access type, multi-access preference, PDU session pair ID, and RSN. It also specifies UE behavior when these conditions are not met, for example: “the selected route selection descriptor includes the multi-access preference but UE does not support ATSSS, UE shall proceed to step 4” (i.e. skip to the next RSD). Spec-3 discloses dual connectivity based end to end redundant user plane paths, specifically, RSD present, used for redundant PDU sessions and contains RSN.
A POSITA would have been motivated to combine Spec-1, the explicit component set/handling rule of Spec-2, and Spec-3’s dual connectivity based end to end redundant user plane paths, specifically, RSD present, used for redundant PDU sessions and contains RSN in order to align redundant session management with the broader 3GPP-defined route selection framework. The predictable result is a UE that evaluates RSDs containing PDU Session Pair ID/RSN along with other components (preferred access, multi-access preference) and ignores any RSD that contains unsupported components, thereby achieving reliable URSP-based routing. Such combination is obvious because it uses standardized 3GPP handling (Spec-1, Spec-2) to manage RSN (Spec-3), ensuring compatibility with 5G multi-access and redundancy features.
Regarding claim 13 (and method claim 6), Spec-1 teaches the UE, wherein the UE skips the RSD and selects another RSD from the list of RSDs that has a lowest precedence value and has not been evaluated.
However, Spec-2 teaches the UE, wherein the UE skips the RSD and selects another RSD from the list of RSDs that has a lowest precedence value and has not been evaluated (Section 4.2.2.2 pg. 10, “the UE shall select a route selection descriptor with the next smallest precedence value which has not yet been evaluated…”[Wingdings font/0xE0]matches skip and evaluate next lowest precedence RSD).
Spec-1 discloses the overall URSP evaluation method: the UE evaluates URSP rules in order, matches traffic descriptors to application information, selects/evaluates RSDs, and considers them valid only if access type preference, multi-access preference, or other validity conditions are met. Spec-2 explicitly enumerates the RSD component set, including preferred access type, multi-access preference, PDU session pair ID, and RSN. It also specifies UE behavior when these conditions are not met, for example: “the selected route selection descriptor includes the multi-access preference but UE does not support ATSSS, UE shall proceed to step 4” (i.e. skip to the next RSD). Spec-3 discloses dual connectivity based end to end redundant user plane paths, specifically, RSD present, used for redundant PDU sessions and contains RSN.
A POSITA would have been motivated to combine Spec-1, the explicit component set/handling rule of Spec-2, and Spec-3’s dual connectivity based end to end redundant user plane paths, specifically, RSD present, used for redundant PDU sessions and contains RSN in order to align redundant session management with the broader 3GPP-defined route selection framework. The predictable result is a UE that evaluates RSDs containing PDU Session Pair ID/RSN along with other components (preferred access, multi-access preference) and ignores any RSD that contains unsupported components, thereby achieving reliable URSP-based routing. Such combination is obvious because it uses standardized 3GPP handling (Spec-1, Spec-2) to manage RSN (Spec-3), ensuring compatibility with 5G multi-access and redundancy features.
Regarding claim 14 (and method claim 7), Spec-1 fails to teach the UE, wherein the UE skips the selected URSP rule when there is no other RSD from the list of RSDs that has not been evaluated.
However, Spec-2 teaches the UE, wherein the UE skips the selected URSP rule when there is no other RSD from the list of RSDs that has not been evaluated (Section 4.2.2.2 pg. 11, “if all route selection descriptors for the matching non-default URSP rule have been evaluated…the UE shall proceed to [evaluate] the next URSP rule…”[Wingdings font/0xE0]maps to skips URSP when no remaining unevaluated RSD exists).
Spec-1 discloses the overall URSP evaluation method: the UE evaluates URSP rules in order, matches traffic descriptors to application information, selects/evaluates RSDs, and considers them valid only if access type preference, multi-access preference, or other validity conditions are met. Spec-2 explicitly enumerates the RSD component set, including preferred access type, multi-access preference, PDU session pair ID, and RSN. It also specifies UE behavior when these conditions are not met, for example: “the selected route selection descriptor includes the multi-access preference but UE does not support ATSSS, UE shall proceed to step 4” (i.e. skip to the next RSD). Spec-3 discloses dual connectivity based end to end redundant user plane paths, specifically, RSD present, used for redundant PDU sessions and contains RSN.
A POSITA would have been motivated to combine Spec-1, the explicit component set/handling rule of Spec-2, and Spec-3’s dual connectivity based end to end redundant user plane paths, specifically, RSD present, used for redundant PDU sessions and contains RSN in order to align redundant session management with the broader 3GPP-defined route selection framework. The predictable result is a UE that evaluates RSDs containing PDU Session Pair ID/RSN along with other components (preferred access, multi-access preference) and ignores any RSD that contains unsupported components, thereby achieving reliable URSP-based routing. Such combination is obvious because it uses standardized 3GPP handling (Spec-1, Spec-2) to manage RSN (Spec-3), ensuring compatibility with 5G multi-access and redundancy features.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure:
3GPP TS23.503 v16.9.0 5G; Policy and charging control framework for the 5G System (5Gs); Stage 2
Seokjung et al (US20210250788) discloses a method and apparatus for supporting redundant PDU sessions.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MICHAEL WILLIAM ABBATINE whose telephone number is (571)272-0192. The examiner can normally be reached Monday-Friday 0830-1700 EST.
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, Nishant Divecha can be reached at (571) 270-3125. 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.
/MICHAEL WILLIAM ABBATINE JR./Examiner, Art Unit 2419
/Nishant Divecha/Supervisory Patent Examiner, Art Unit 2419
Prosecution Insights