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 Applicant’s amendment filed 7/21/2026. Claims 3, 5, 12-14, 16-31, 34, 40-42, 46-48, and 50-52 have been cancelled. Claims 1, 4, 8, 11, 36, 39, 45, and 49 have been amended. Claims 1, 2, 4, 6-11, 15, 32, 33, 35-39, 43-45, and 49 are currently pending.
Claim Rejections - 35 USC § 102
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 the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
Claim(s) 1, 2, 4, 45, and 49 is/are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Keller et al., (US 20150304899, hereinafter referred to as “Keller”).
Regarding claim 1, Keller teaches a method performed by a first service enabler server (abstract - Application Server allocated to the User Equipment), comprising:
receiving context information of a second service enabler server from the second service enabler server (figures 2-4: session/routing information is transmitted between application servers during service continuity procedures);
after the receiving of the context information, sending endpoint information of the first service enabler server to a service enabler client and/or initiating a traffic influence procedure with a network to request replacement of endpoint information of the second service enabler server with the endpoint information of the first service enabler server (abstract - A routing identifier is established that identifies a Service Centralization and Continuity Application Server allocated to the User Equipment. The routing identifier is sent to the User Equipment. In the event of disruption to the service between the User Equipment and the Service Centralization and Continuity Application Server, a handover message is sent from the User Equipment via a Circuit Switched access network. The handover message includes the routing identifier, and is then forwarded to the identified Service Centralization and Continuity Application Server. This allows the same Service Centralization and Continuity Application Server to be used after the handover as was used before the handover, thereby providing service continuity.).
Regarding claim 2, Keller teaches the method according to claim 1, wherein receiving context information of a second service enabler server from the second service enabler server comprises: sending a context pull request to the second service enabler server; and receiving a context pull response comprising the context information of the second service enabler server from the second service enabler server, or receiving context information of a second service enabler server from the second service enabler server comprises: receiving a context push request comprising the context information of the second service enabler server from the second service enabler server; and sending a context push response to the second service enabler server (figures 2-4: session/routing information is transferred between nodes as part of service continuity. [0029] - Signaling may include SIP, which inherently includes request/response exchanges for session transfer. Such exchange inherently corresponds to push and pull of context information).
Regarding claim 4, Keller teaches the method according to claim 1, wherein the context information of the second service enabler server comprises at least one of: service subscription information created upon an application server's interaction for requesting a data transmission service of the second service enabler server, service enabler client communication tunnel management information created upon the service enabler client's interaction for requesting a data transmission service of the second service enabler server, or service enabler server communication tunnel management information created upon the service enabler client's interaction for requesting a data transmission service of the second service enabler server (figures 2-4: session/routing information. Session related subscription is inherent in IMS service handling).
Regarding claim 45, Keller teaches a first service enabler server (abstract - Application Server allocated to the User Equipment), comprising:
a processor ([0015] processor); and
a memory coupled to the processor ([0015] memory), said memory containing instructions executable by said processor, whereby the first service enabler server is operative to: receive context information of a second service enabler server from the second service enabler server (figures 2-4: session/routing information is transmitted between application servers during service continuity procedures);
after the receiving of the context information, send endpoint information of the first service enabler server to a service enabler client and/or initiate a traffic influence procedure with a network to request replacement of endpoint information of the second service enabler server with the endpoint information of the first service enabler server (abstract - A routing identifier is established that identifies a Service Centralization and Continuity Application Server allocated to the User Equipment. The routing identifier is sent to the User Equipment. In the event of disruption to the service between the User Equipment and the Service Centralization and Continuity Application Server, a handover message is sent from the User Equipment via a Circuit Switched access network. The handover message includes the routing identifier, and is then forwarded to the identified Service Centralization and Continuity Application Server. This allows the same Service Centralization and Continuity Application Server to be used after the handover as was used before the handover, thereby providing service continuity.).
Regarding claim 49, Keller teaches a service enabler client ([0015] UE), comprising:
a processor ([0015] processor); and
a memory coupled to the processor ([0015] memory), said memory containing instructions executable by said processor, whereby the service enabler client is operative to: receive endpoint information of a first service enabler server from the first service enabler server, wherein the endpoint information is sent from the first service enabler server after context information of a second service enabler server is received by the first service enabler server from the second service enabler (abstract - A routing identifier is established that identifies a Service Centralization and Continuity Application Server allocated to the User Equipment. The routing identifier is sent to the User Equipment. In the event of disruption to the service between the User Equipment and the Service Centralization and Continuity Application Server, a handover message is sent from the User Equipment via a Circuit Switched access network. The handover message includes the routing identifier, and is then forwarded to the identified Service Centralization and Continuity Application Server. This allows the same Service Centralization and Continuity Application Server to be used after the handover as was used before the handover, thereby providing service continuity.).
Claim(s) 1, 2, 4, 6-11, 15, 33, 35-39, 43-45, and 49 is/are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Seed et al., (WO 2021126948, hereinafter referred to as “Seed”).
Regarding claim 1, Seed teaches a method performed by a first service enabler server (figure 2: edge enabler server), comprising:
receiving context information of a second service enabler server from the second service enabler server ([0018], teaches an Edge Application Handover Server (EAHS), which may be implemented as a V2X Application Enabler Server, SEAL Server, Edge Enabler Server, Edge Data Network Configuration Server, oneM2M CSE, or LWM2 server. [0077] - [0079] teaches how the EAHS can receive context information pertaining to edge enabler servers);
after the receiving of the context information, sending endpoint information of the first service enabler server to a service enabler client or initiating a traffic influence procedure with a network to request replacement of endpoint information of the second service enabler server with the endpoint information of the first service enabler server ([0032] – [0033] of Seed teach EAHS receiving context and then using the context to determine whether and edge application handover should occur. The context can be used to determine next EAS and that the EAHS can subsequently perform operations with the handover).
Regarding claim 2, Seed teaches the method according to claim 1, wherein receiving context information of a second service enabler server from the second service enabler server comprises: sending a context pull request to the second service enabler server; and receiving a context pull response comprising the context information of the second service enabler server from the second service enabler server, or receiving context information of a second service enabler server from the second service enabler server comprises: receiving a context push request comprising the context information of the second service enabler server from the second service enabler server; and sending a context push response to the second service enabler server ([0010] An EAHC may issue requests to one or more EAHSs in the network to have them assist with EAH operations. [0014] An EAHC may perform establishment and tear-down of security sessions in an EAH aware manner on behalf of an AC. These operations may be performed by the EAHC when it triggers an EAH or in response to an EAH request that it receives from an AC or EAHS. Such exchange of request/response inherently corresponds to push and pull of context information).
Regarding claim 4, Seed teaches the method according to claim 1, wherein the context information of the second service enabler server comprises at least one of: service subscription information created upon an application server's interaction for requesting a data transmission service of the second service enabler server, service enabler client communication tunnel management information created upon the service enabler client's interaction for requesting a data transmission service of the second service enabler server, or service enabler server communication tunnel management information created upon the service enabler client's interaction for requesting a data transmission service of the second service enabler server (abstract - he handover client may issue requests to servers requesting assistance in handover operations, and may issue subscription requests to servers, and further may determine the success of handovers by monitoring application state synchronization or migration between edge application handover servers.).
Regarding claim 6, teaches the method according to claim 4, wherein the context information of the second service enabler server further comprises transport layer context ([00177] The core network 106/107/109 may also serve as a gateway for the WTRUs 102a, 102b, 102c, 102d, 102e to access the PSTN 108, the Internet 110, and/or other networks 112. The PSTN 108 may include circuit-switched telephone networks that provide plain old telephone service (POTS). The Internet 110 may include a global system of interconnected computer networks and devices that use common communication protocols, such as the transmission control protocol (TCP), user datagram protocol (UDP) and the internet protocol (IP) in the TCP/IP internet protocol suite).
Regarding claim 7, Seed teaches the method according to claim 1, wherein endpoint information of a service enabler server comprises at least one of: a Uniform Resource Identifier (URI), a Fully Qualified Domain Name (FQDN), an Internet protocol (IP) address of user plane communication, or a port number of user plane communication ([0013] An EAHC may perform EAS FQDN resolution assistance operations when an EAH occurs. To minimize impact of an EAH on an AC and allow the AC to continue to use the same EAS FQDN before and after an EAH occurs, the EAHC may perform EAS FQDN resolution operations on behalf of an AC. This enables ACs to use the same EAS FQDNs to communicate with EASs even after an EAH has occurred.).
Regarding claim 8, Seed teaches the method according to claim 1, wherein, if service enabler server is adapted to edge application (EDGEAPP) as an edge application server (EAS), an EAS relocation procedure is used to support service enabler server relocation for both user equipment (UE) mobility and service enabler server load re-balance ([0133] an EAHC or EAHS may provide EAH related context regarding where an EAS could be deployed (e.g., on a set of edge nodes such that load balancing or performance scaling could be performed by managing the EAS status on these nodes), when an EAH is required (e.g., immediately or some specified time or schedule in the future), where an EAH is required (e.g., within a specified geographic location or region, within a specified area of the network such as within a designated edge network, or along a specified route), who an EAH is required for (e.g., which UE, AC, EAS, edge node) and why an EAH is required (e.g., UE has changed location, AC is not satisfied with level of service from current EAS, 3GPP network has signaled an issue such as network congestion)); or
if service enabler server is not adapted to EDGEAPP, for UE mobility, the first service enabler server is discovered by the service enabler client and a new communication channel including old communication channel information is established by the service enabler client, and for service enabler server load re-balance, the first service enabler server is discovered by the second service enabler server ( [00134] An EAHC or EAHS may also determine that a specific management operation is required (Step 4) and may send a trigger request to a management function (Step 5) to have it perform a specific type of management operation on its behalf (Step 6) such as but not limited to deploying an EAS in a specified edge network or on a specified edge node, installing and activating/deactivating an EAS in a specified edge network or on a specified edge node.).
Regarding claim 9, Seed teaches the method according to claim 1, wherein during service enabler server relocation with user plane function (UPF) change, existing unfinished application traffic flow toward an old application server is handled by a new UPF and an inter-UPF tunnel is used to forward the existing unfinished application traffic flow, and new application traffic flow which has UE's new IP address as source IP address is sent directly by the first service enabler server to a new application server ([0016] An EAHC may buffer outgoing requests from ACs towards EASs while EAH operations are being performed (e.g., refreshing DNS lookup results, migrating state information to a new EAS, etc.). When EAH operations are completed and a new EAS is accessible, an EAHC may forward these requests to the new EAS for processing.).
Regarding claim 10, Seed teaches the method according to claim 1, further comprising: sending a registration request comprising a profile of the first service enabler server to an edge enabler server (EES), wherein the profile of the first service enabler server comprises information indicating supporting transport layer context transfer; and receiving a registration response from the EES ([00204] As shown in Figure 26E, the RAN 105 may include base stations 180a, 180b, 180c, and an ASN gateway 182, though it will be appreciated that the RAN 105 may include any number of base stations and ASN gateways while remaining consistent with an embodiment. The base stations 180a, 180b, 180c may each be associated with a particular cell in the RAN 105 and may include one or more transceivers for communicating with the WTRUs 102a, 102b, 102c over the air interface 117. In an embodiment, the base stations 180a, 180b, 180c may implement MIMO technology. Thus, the base station 180a, for example, may use multiple antennas to transmit wireless signals to, and receive wireless signals from, the WTRU 102a. The base stations 180a, 180b, 180c may also provide mobility management functions, such as handoff triggering, tunnel establishment, radio resource management, traffic classification, quality of service (QoS) policy enforcement, and the like. The ASN gateway 182 may serve as a traffic aggregation point and may be responsible for paging, caching of subscriber profiles, routing to the core network 109, and the like).
Regarding claim 11, Seed teaches the method according to claim 1, wherein the first service enabler server and/or the second service enabler server support transport layer context transfer ([00177] The core network 106/107/109 may also serve as a gateway for the WTRUs 102a, 102b, 102c, 102d, 102e to access the PSTN 108, the Internet 110, and/or other networks 112. The PSTN 108 may include circuit-switched telephone networks that provide plain old telephone service (POTS). The Internet 110 may include a global system of interconnected computer networks and devices that use common communication protocols, such as the transmission control protocol (TCP), user datagram protocol (UDP) and the internet protocol (IP) in the TCP/IP internet protocol suite).
Regarding claim 15, Seed teaches the method according to claim 1, wherein an old data transmission path is established via an application client, the service enabler client, the second service enabler server and an application server, and a new data transmission path is to be established via the application client, the service enabler client, the first service enabler server and the application server ([0088] EASs will typically be deployed on different edge nodes in the system. Each EAS will have unique point-of-contact(s) including IP address(s), port(s) and URI path(s) for the services and resources that they offer. Accessing a given EAS requires an AC to send requests to an EAS's point-of-contact. If/when a handover to a new EAS occurs, a change in point-of-contact information will occur. A change in point-of-contact information of an EAS, can have a significant impact on ACs. It is not uncommon for point-of-contact information of EASs to be directly configured and/or coded into ACs. Hence if a change occurs to point- of-contact information of an EAS, this typically will require the AC to be made aware of this change. An AC must then stop its communication with the old EAS, initiate the teardown of various types of sessions (e.g., PDU, QoS, security) between the AC and the old EAS and establish corresponding sessions with the new EAS. This tear-down and re-establishment of the various types of sessions requires that new sessions be configured in a consistent manner as the prior ones such that the handover occurs seamlessly. This also needs to take place in a timely manner such that no disruptions in service occur for the AC.).
Regarding claim 33, Seed teaches the method according to claim 11, wherein the context information of the second service enabler server comprises at least one of: service subscription information created upon an application server's interaction for requesting a data transmission service of the second service enabler server, service enabler client communication tunnel management information created upon the service enabler client's interaction for requesting a data transmission service of the second service enabler server, or service enabler server communication tunnel management information created upon the service enabler client's interaction for requesting a data transmission service of the second service enabler server ([0011] An EAHC may issue subscription request(s) to an EAHS in the network to receive notifications from the EAHS. One type of subscription may to be receive notifications if/when the EAHS determines that an AC should be handed off from one EAS to another. [0012] Based on subscription requests to an EAHS, the EAHC may receive notifications from the EAHS. One type of notification may be a trigger to the EAHC to perform EAH operations for one or more designated ACs.).
Regarding claim 35, Seed teaches the method according to claim 11, wherein the context information of the second service enabler server further comprises transport layer context ([00177] The core network 106/107/109 may also serve as a gateway for the WTRUs 102a, 102b, 102c, 102d, 102e to access the PSTN 108, the Internet 110, and/or other networks 112. The PSTN 108 may include circuit-switched telephone networks that provide plain old telephone service (POTS). The Internet 110 may include a global system of interconnected computer networks and devices that use common communication protocols, such as the transmission control protocol (TCP), user datagram protocol (UDP) and the internet protocol (IP) in the TCP/IP internet protocol suite).
Regarding claim 36, Seed teaches the method according to claim 11, wherein, if service enabler server is adapted to edge application as an edge application server (EAS), an EAS relocation procedure is used to support service enabler server relocation for both user equipment (UE) mobility and service enabler server load re-balance; and/or if service enabler server is not adapted to EDGEAPP, for UE mobility, the first service enabler server is discovered by a service enabler client and a new communication channel including old communication channel information is established by the service enabler client, and for service enabler server load re-balance, the first service enabler server is discovered by the second service enabler server ([0133] an EAHC or EAHS may provide EAH related context regarding where an EAS could be deployed (e.g., on a set of edge nodes such that load balancing or performance scaling could be performed by managing the EAS status on these nodes), when an EAH is required (e.g., immediately or some specified time or schedule in the future), where an EAH is required (e.g., within a specified geographic location or region, within a specified area of the network such as within a designated edge network, or along a specified route), who an EAH is required for (e.g., which UE, AC, EAS, edge node) and why an EAH is required (e.g., UE has changed location, AC is not satisfied with level of service from current EAS, 3GPP network has signaled an issue such as network congestion)).
Regarding claim 37, Seed teaches the method according to claim 11, wherein during service enabler server relocation with UPF change, existing unfinished application traffic flow toward an old application server is handled by a new UPF and an inter-UPF tunnel is used to forward the existing unfinished application traffic flow, and new application traffic flow which has UE's new IP address as source IP address is sent directly by the first service enabler server to a new application server ([0016] An EAHC may buffer outgoing requests from ACs towards EASs while EAH operations are being performed (e.g., refreshing DNS lookup results, migrating state information to a new EAS, etc.). When EAH operations are completed and a new EAS is accessible, an EAHC may forward these requests to the new EAS for processing.).
Regarding claim 38, Seed teaches the method according to claim 11, further comprising: sending a discovery request for discovering service enabler server supporting transport layer context transfer to an EES; and receiving a registration response comprising information about discovered service enabler server supporting transport layer context transfer from the EES ([0025] An EAHS may interface to management function(s) in the system to query and discover available edge nodes that host (or that are capable of hosting) one or more specified types of EASs.).
Regarding claim 39, Seed teaches the method according to claim 11 wherein the first service enabler server and/or the second service enabler server support transport layer context transfer ([00177] The core network 106/107/109 may also serve as a gateway for the WTRUs 102a, 102b, 102c, 102d, 102e to access the PSTN 108, the Internet 110, and/or other networks 112. The PSTN 108 may include circuit-switched telephone networks that provide plain old telephone service (POTS). The Internet 110 may include a global system of interconnected computer networks and devices that use common communication protocols, such as the transmission control protocol (TCP), user datagram protocol (UDP) and the internet protocol (IP) in the TCP/IP internet protocol suite).
Regarding claim 43, Seed teaches the method according to claim 11, wherein an old data transmission path is established via an application client, a service enabler client, the second service enabler server and an application server, and a new data transmission path is to be established via the application client, the service enabler client, the first service enabler server and the application server ([0088] EASs will typically be deployed on different edge nodes in the system. Each EAS will have unique point-of-contact(s) including IP address(s), port(s) and URI path(s) for the services and resources that they offer. Accessing a given EAS requires an AC to send requests to an EAS's point-of-contact. If/when a handover to a new EAS occurs, a change in point-of-contact information will occur. A change in point-of-contact information of an EAS, can have a significant impact on ACs. It is not uncommon for point-of-contact information of EASs to be directly configured and/or coded into ACs. Hence if a change occurs to point- of-contact information of an EAS, this typically will require the AC to be made aware of this change. An AC must then stop its communication with the old EAS, initiate the teardown of various types of sessions (e.g., PDU, QoS, security) between the AC and the old EAS and establish corresponding sessions with the new EAS. This tear-down and re-establishment of the various types of sessions requires that new sessions be configured in a consistent manner as the prior ones such that the handover occurs seamlessly. This also needs to take place in a timely manner such that no disruptions in service occur for the AC.).
Regarding claim 44, Seed teaches the method according to claim 11, wherein endpoint information of a service enabler server comprises at least one of: a Uniform Resource Identifier, a Fully Qualified Domain Name, an Internet protocol address of user plane communication, or a port number of user plane communication ([0013] An EAHC may perform EAS FQDN resolution assistance operations when an EAH occurs. To minimize impact of an EAH on an AC and allow the AC to continue to use the same EAS FQDN before and after an EAH occurs, the EAHC may perform EAS FQDN resolution operations on behalf of an AC. This enables ACs to use the same EAS FQDNs to communicate with EASs even after an EAH has occurred. Thus, ACs are not burdened with managing lower level EAS point-of-contact information (e.g., IP addresses, ports, URIs) which can become stale after an EAH occurs. Instead, the EAHC can handle this burden on behalf of an AC).
Regarding claim 45, Seed teaches a first service enabler server, comprising: a processor (Figure 26B, the example WTRU 102 may include a processor 118); and a memory (figure 26B, memory 130, 132) coupled to the processor, said memory containing instructions executable by said processor, whereby the first service enabler server is operative to: receive context information of a second service enabler server from the second service enabler server; after the receiving of the context information, send endpoint information of the first service enabler server to a service enabler client and/or initiate a traffic influence procedure with a network to request replacement of endpoint information of the second service enabler server with the endpoint information of the first service enabler server (abstract - The handover client may weigh the needs of multiple application clients m selecting servers for handovers. The handover client may issue requests to servers requesting assistance in handover operations, and may issue subscription requests to servers, and further may determine the success of handovers by monitoring application state synchronization or migration between edge application handover servers.).
Regarding claim 49, Seed teaches a service enabler client ([0004] Edge Enabler Client), comprising: a processor (processor 118); and a memory (memory 130) coupled to the processor, said memory containing instructions executable by said processor, whereby the service enabler client is operative to: receive endpoint information of a first service enabler server from the first service enabler server, wherein the endpoint information is sent from the first service enabler server after context information of a second service enabler server is received by the first service enabler server from the second service enabler (abstract - The handover client may weigh the needs of multiple application clients m selecting servers for handovers. The handover client may issue requests to servers requesting assistance in handover operations, and may issue subscription requests to servers, and further may determine the success of handovers by monitoring application state synchronization or migration between edge application handover servers.).
Allowable Subject Matter
Claim 32 is allowed in view of Applicant’s persuasive argument.
Response to Arguments
Claim Rejections - 35 USC § 112
The rejections are withdrawn in view of Applicant’s persuasive arguments.
Claim Rejections - 35 USC § 102
Applicant's arguments filed July 21, 2026, have been fully considered but they are not persuasive.
Page 10 of 14 of the remarks, Applicant argues that Keller fails to teach or suggest the bolded claim limitations.
1. A method performed by a first service enabler server, comprising:
receiving context information of a second service enabler server from the second service enabler server; and
after the receiving of the context information, sending endpoint information of the first service enabler server to a service enabler client or initiating a traffic influence procedure with a network to request replacement of endpoint information of the second service enabler server with the endpoint information of the first service enabler server.
Although the claim specifies that certain information is received between the first service enabler server, the second service enabler, and the service enabler client, no where in the claim does it state that the “first” and “second” are two different servers. Therefore, Keller’s teaching of SCC AS 4 can be construed as both first and second service enabler server roles.
As cited in the rejection above, abstract, as well as figures 2-4 of Keller illustrate SCC AS 4, has a routing identifier, and that the routing identifier is sent to the UE. Thus, the routing identifier is interpreted as the claimed server-related context used to identify/reach the SCC AS.
Figure 2 of Keller illustrates the sequence involving the SCC AS’s routing identifier and subsequent network routing. For example, the SCC AS is allocated to the UE, the routing identifier is sent to the UE, the UE later loses Gm capability, the UE sends a handover request containing the routing identifier, HRL uses the identifier to identify the SCC AS, and the HLR forwards the handover message to that SCC AS. Therefore, Keller teaches the claimed “after the receiving” step.
Claims 45 and 49 are similar to claim 1, therefore the rejection is sustained under the same rationale.
On page 11 of 14, Applicant argues that Seed does not teach the claimed invention. The argument is the same as that of Keller. In response, the Patent Office respectfully disagrees and submits that Seed does teach the claimed invention.
Seed, paragraph [0018], teaches an Edge Application Handover Server (EAHS), which may be implemented as a V2X Application Enabler Server, SEAL Server, Edge Enabler Server, Edge Data Network Configuration Server, oneM2M CSE, or LWM2 server. These all are interpreted as the claimed “service enabler server.” As noted above, the claim does not distinguish between the first service enabler server, the second service enabler.
Paragraphs [0020] – [0022] of Seed teach An EAHS may interface entities in 3GPP system and receive context information from these entities. Specifically, [0077] - [0079] teaches how the EAHS can receive context information pertaining to edge enabler servers. Therefore, Seed teaches the claimed “context information.”
Paragraphs [0032] – [0033] of Seed teach EAHS receiving context and then using the context to determine whether and edge application handover should occur. The context can be used to determine next EAS and that the EAHS can subsequently perform operations with the handover. This is interpreted as the claimed “after the receiving” step.
Claims 45 and 49 are similar to claim 1, therefore the rejection is sustained under the same rationale.
Applicant’s argument with regards to the rejection of claim 32 is found persuasive, therefore the rejection is withdrawn.
Remaining rejection dependent claims are sustained because the arguments pertaining to their respective independent claims are not found persuasive and are sustained.
Conclusion
THIS ACTION IS MADE FINAL. 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 ALINA N BOUTAH whose telephone number is (571)272-3908. The examiner can normally be reached M-F 7:00 AM - 3:00 PM.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Umar Cheema can be reached at (571) 270-3037. 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.
ALINA BOUTAH
Primary Examiner
Art Unit 2458
/ALINA A BOUTAH/Primary Examiner, Art Unit 2458
Prosecution Insights