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 .
DETAILED ACTION
Claims 1-18 have been examined and are pending.
Information Disclosure Statement
An initialed and dated copy of Applicant’s IDS form 1449 submitted 09/17/2024 and 10/28/2025, is attached to the instant office action. The submission is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
Double Patenting
The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory double patenting rejection is appropriate where the conflicting claims are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on nonstatutory double patenting provided the reference application or patent either is shown to be commonly owned with the examined application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. See MPEP § 717.02 for applications subject to examination under the first inventor to file provisions of the AIA as explained in MPEP § 2159. See MPEP § 2146 et seq. for applications not subject to examination under the first inventor to file provisions of the AIA . A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b).
The filing of a terminal disclaimer by itself is not a complete reply to a nonstatutory double patenting (NSDP) rejection. A complete reply requires that the terminal disclaimer be accompanied by a reply requesting reconsideration of the prior Office action. Even where the NSDP rejection is provisional the reply must be complete. See MPEP § 804, subsection I.B.1. For a reply to a non-final Office action, see 37 CFR 1.111(a). For a reply to final Office action, see 37 CFR 1.113(c). A request for reconsideration while not provided for in 37 CFR 1.113(c) may be filed after final for consideration. See MPEP §§ 706.07(e) and 714.13.
The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The actual filing date of the application in which the form is filed determines what form (e.g., PTO/SB/25, PTO/SB/26, PTO/AIA /25, or PTO/AIA /26) should be used. A web-based eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about eTerminal Disclaimers, refer to www.uspto.gov/patents/apply/applying-online/eterminal-disclaimer.
Claim 1-18 is rejected on the ground of nonstatutory double patenting as being unpatentable over claim 1-18 of U.S. Patent No. 12,133,277. Although the claims at issue are not identical, they are not patentably distinct from each other because:
Instant Application
Patent 12,133,277
1. A method for use in a wireless transmit/receive unit (WTRU), the method comprising:
1. A method for use in a wireless transmit/receive unit (WTRU), the method comprising:
determining, for an application that is requesting network access, a classification associated with the application;
determining, for a first application that is requesting network access, a classification associated with the first application;
determining, based on configuration information, a service session continuity (SSC) mode for the application, wherein the configuration information includes mapping information between the classification associated with the application and the SSC mode; and
determining, based on configuration information, a first service session continuity (SSC) mode for the first application, wherein the configuration information includes mapping information between the classification associated with the first application and the first SSC mode
transmitting, based at least on the determined SSC mode being different than an SSC mode associated with an existing Packet Data Unit (PDU) session, a PDU session establishment request with the determined SSC mode for a new PDU session to be associated with the application.
transmitting, based on the determined first SSC mode being different than a second SSC mode associated with an existing first Packet Data Unit (PDU) session, a first PDU session establishment request with the determined first SSC mode for a new second PDU session to be associated with the first application;
determining, for a second application that is requesting network access, a classification associated with the second application; determining, based on the configuration information, a third SSC mode for the second application, wherein the configuration information further includes mapping information between the classification associated with the second application and the third SSC mode; and transmitting, based on at least the determined third SSC mode being different than the first SSC mode associated with the second PDU session, a second PDU session establishment request with the determined third SSC mode for a new third PDU session to be associated with the second application.
Patent 12,133,277 includes additional limitations regarding a second application. However, it would be obvious to one of ordinary skilled in the art to remove the additional limitations regarding the second application to arrive at the same invention as the instant application.
Regarding Claim 2, Patent 12,133,277 teaches The method of claim 1, further comprising: transmitting, based on the determined SSC mode being same as the SSC mode associated with the existing PDU session, data associated with the application using the existing PDU session. (Claim 2, “transmitting, based on the determined first SSC mode being the same as the second SSC mode associated with the existing first PDU session, data associated with the first application using the existing first PDU session”)
Regarding Claim 3, Patent 12,133,277 teaches The method of claim 1, wherein the PDU session establishment request is a first PDU session establishment request, the method further comprising: transmitting, based on a determination that no PDU session has been established, a second PDU session establishment request with the determined SSC mode. (Claim 3, “transmitting, based on a determination that no PDU session has been established, a third PDU session establishment request with the determined first SSC mode”)
Regarding Claim 4, Patent 12,133,277 teaches The method of claim 1, wherein the determined SSC mode is one of SSC mode 1, SSC mode 2 or SSC mode 3, and wherein the SSC mode associated with the existing PDU session is one of SSC mode 1, SSC mode 2 or SSC mode 3. (Claim 4, “wherein the first SSC mode, the second SSC mode, and the third SSC mode are each one of SSC mode 1, SSC mode 2 or SSC mode 3”)
Regarding Claim 5, Patent 12,133,277 teaches The method of claim 4, wherein the SSC mode 3 allows the WTRU to establish the new PDU session before the existing PDU session is terminated. (Claim 5, “wherein the SSC mode 3 allows the WTRU to establish the new second PDU session before the existing first PDU session is terminated.”)
Regarding Claim 6, Patent 12,133,277 teaches The method of claim 1, further comprising: determining, based on predetermined configuration information, the SSC mode for the application, wherein the predetermined configuration information includes the mapping information between the classification associated with the application and the SSC mode. (Claim 6, “determining, based on predetermined configuration information, the first SSC mode for the first application, wherein the predetermined configuration information includes the mapping information between the classification associated with the first application and the first SSC mode.”)
Regarding Claim 7, Patent 12,133,277 teaches The method of claim 1, further comprising: receiving an indication that the application has been launched, wherein the indication indicates the classification associated with the application. (Claim 7, “receiving a first indication that the first application has been launched, wherein the first indication indicates the classification associated with the first application;”)
Regarding Claim 8, Patent 12,133,277 teaches The method of claim 1, further comprising: receiving, from the application, a request for a network connection, wherein the request comprises an indication of the classification associated with the application. (Claim 8, “receiving, from the first application, a first request for a network connection, wherein the first request comprises an indication of the classification associated with the first application;”)
Regarding Claim 9, Patent 12,133,277 teaches The method of claim 1, wherein the classification associated with the application comprises an application class associated with the application. (Claim 9, “wherein the classification associated with the first application comprises an application class associated with the first application”)
Claim 10-18 are rejected for the same reasons as claims 10-18 of Patent 12,133,277.
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.
Claim(s) 1-3, 6-12, 15-18 is/are rejected under 35 U.S.C. 103 as being unpatentable over US 2017/0290082 to Salkintzis et al. (hereinafter “Salkintzis”) in view of US 2015/0029956 A1 to Moses et al. (hereinafter “Moses”)
Regarding Claim 1, Salkintzis teaches A method for use in a wireless transmit/receive unit (WTRU), the method comprising:(Figure 2 and [0098], illustrates a remote unit 105. Remote units 105 may be referred to as subscriber units, mobiles, mobile stations, users, terminals, mobile terminals, fixed terminals, subscriber stations, UE, user terminals, a device, or by other terminology used in the art (WTRU))
determining, for an application that is requesting network access, a classification associated with the application; ([0053], discloses the processor receives the data session request from an application, wherein the processor identifies the required continuity type further based on an identity of the application)
determining, based on configuration information, a service session continuity (SSC) mode for the application, wherein the configuration information includes mapping information between the classification associated with the application and the SSC mode; and ([0047], discloses the apparatus further includes a storage device having a continuity selection policy (i.e. configuration information). The continuity selection policy may include one or more prioritized rules for selecting a required continuity type based on one or more data session characteristics (i.e. mapping information between application characteristic and SSC mode). The processor may apply the continuity selection policy to a data session to identify the required continuity type)
transmitting, based at least on the determined SSC mode being different than an SSC mode associated with an existing Packet Data Unit (PDU) session, a PDU session establishment request with the determined SSC mode for a new PDU session to be associated with the application. ([0051], discloses the processor receives a second data session request and identifies a second required continuity type based on the data session request. The processor also requests a new PDU session having the second required continuity type (i.e. PDU session establishment request with determined SSC mode) in response to the second required continuity type not matching (i.e. determined SSC mode being different) the continuity type of the established PDU session)
Salkintzis teaches mapping information between different characteristics of an application and different continuity types (see ([0047] and [0053], Figure 8 and [0161]-[0167]) but does not explicitly teach the mapping information between a classification associated with the application and the SSC mode.
However, the concept of determining a session continuity type based on an application type is well known in the art. For example, in a similar field of endeavor, Moses discloses in [0079], identifying session continuity on a per-application basis. [0081], discloses an alternative embodiment, in which a client side of an IP session, for example, mobile device 102, may be configured to determine whether IP session continuity is to be guaranteed for the IP session. For example, application 147 and/or controller 145 may be configured to determine whether an IP session, which is to be initiated between mobile device 102 and server 180, is to be classified as an IP session requiring IP session continuity or as an IP session not requiring IP session continuity (i.e. SSC modes), e.g., based on the type of application 147 (i.e. classification associated with application), a type of traffic to be communicated during the IP session, and/or any other information corresponding to the IP session.
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Salkintzis to include the above limitations as suggested by Moses, as selectively providing IP session continuity based on application type reduces consumption of network resources as indicated in [0006] of Moses.
Regarding Claim 2, Salkintzis/Moses teaches The method of claim 1, further comprising: Salkintzis further teaches transmitting, based on the determined SSC mode being same as the SSC mode associated with the existing PDU session, data associated with the application using the existing PDU session. ([0051] discloses The processor routes the second data session through an established PDU session in response to the second required continuity type matching the continuity type of the established PDU session)
Regarding Claim 3, Salkintzis/Moses teaches The method of claim 1, wherein Salkintzis further teaches the PDU session establishment request is a first PDU session establishment request, the method further comprising: transmitting, based on a determination that no PDU session has been established, a second PDU session establishment request with the determined SSC mode. ([0049], discloses the processor detects a termination of the data session and determines whether the PDU session becomes inactive for at least a threshold inactivity period, wherein a PDU session becomes inactive in response to no open data sessions requiring the continuity type corresponding to that PDU session. In such embodiments, the processor terminates the PDU session in response to the PDU session being inactive for at least a threshold inactivity period. Figure 9 and [0170]-[0171], discloses receiving a data session request, identifying a required continuity type based on the data session request, and establish a PDU session having the required continuity type. Examiner further notes that no PDU session has been established is also indicative of no matching SSC modes with an existing PDU session)
Regarding Claim 6, Salkintzis/Moses teaches The method of claim 1, further comprising: Salkintzis further teaches determining, based on predetermined configuration information, the SSC mode for the application, wherein the predetermined configuration information includes the mapping information between the classification associated with the application and the SSC mode. ([0047], discloses In some embodiments, the apparatus further includes a storage device having a continuity selection policy (i.e. configuration information). The continuity selection policy may include one or more prioritized rules for selecting a required continuity type based on one or more data session characteristics. The processor may apply the continuity selection policy to a data session to identify the required continuity type (i.e. SSC mode). In one embodiment, the continuity selection policy is provisioned by the mobile communication network (i.e. predetermined configuration information). [0053], discloses each PDU session is assigned a continuity type. In certain embodiments, the processor receives the data session request from an application, wherein the processor identifies the required continuity type further based on an identity of the application (i.e. mapping information))
Regarding Claim 7, Salkintzis/Moses teaches The method of claim 1, further comprising:
Salkintzis further teaches receiving an indication that the application has been launched, ([0127], discloses at some point, the application 304 requests a data session. For example, the application 304 may
Salkintzis/Moses further teaches wherein the indication indicates the classification associated with the application. (Salkintzis, [0053], discloses identifying the required continuity type further based on an identity of the application. [0169], discloses the data session request may include one or more parameters, including, but not limited to, an identity of the requesting application, a destination address, a destination domain name, a destination port number, and a transfer protocol. Moses, [0082], discloses determining session continuity based on type of application)
Examiner maintains same motivation to combine as indicated in claim 1 above.
Regarding Claim 8, Salkintzis/Moses teaches The method of claim 1, further comprising:
Salkintzis further teaches receiving, from the application, a request for a network connection, ([0127], discloses at some point, the application 304 requests a data session. For example, the application 304 may start a new IP session by sending a new IP session request 320 to the OS 308 )
Salkintzis/Moses further teaches wherein the request comprises an indication of the classification associated with the application. (Salkintzis, [0053], discloses identifying the required continuity type further based on an identity of the application. [0169], discloses the data session request may include one or more parameters, including, but not limited to, an identity of the requesting application, a destination address, a destination domain name, a destination port number, and a transfer protocol. Moses, [0082], discloses determining session continuity based on type of application)
Examiner maintains same motivation to combine as indicated in claim 1 above.
Regarding Claim 9, Salkintzis/Moses teaches The method of claim 1, wherein
Moses further teaches the classification associated with the application comprises an application class associated with the application.([0081], discloses For example, application 147 and/or controller 145 may be configured to determine whether an IP session, which is to be initiated between mobile device 102 and server 180, is to be classified as an IP session requiring IP session continuity or as an IP session not requiring IP session continuity, e.g., based on the type of application 147 (i.e. application class), a type of traffic to be communicated during the IP session, and/or any other information corresponding to the IP session)
Regarding Claim 10, Salkintzis teaches A wireless transmit/receive unit (WTRU), comprising a processor configured to :(Figure 2 and [0098], illustrates a remote unit 105 comprising processor and transceiver. Remote units 105 may be referred to as subscriber units, mobiles, mobile stations, users, terminals, mobile terminals, fixed terminals, subscriber stations, UE, user terminals, a device, or by other terminology used in the art (WTRU))
determine, for an application that is requesting network access, a classification associated with the application; ([0053], discloses the processor receives the data session request from an application, wherein the processor identifies the required continuity type further based on an identity of the application)
determine, based on configuration information, a service session continuity (SSC) mode for the application, wherein the configuration information includes mapping information between the classification associated with the application and the SSC mode; and ([0047], discloses the apparatus further includes a storage device having a continuity selection policy (i.e. configuration information). The continuity selection policy may include one or more prioritized rules for selecting a required continuity type based on one or more data session characteristics (i.e. mapping information between application characteristic and SSC mode). The processor may apply the continuity selection policy to a data session to identify the required continuity type)
transmit, based at least on the determined SSC mode being different than an SSC mode associated with an existing Packet Data Unit (PDU) session, a PDU session establishment request with the determined SSC mode for a new PDU session to be associated with the application. ([0051], discloses the processor receives a second data session request and identifies a second required continuity type based on the data session request. The processor also requests a new PDU session having the second required continuity type (i.e. PDU session establishment request with determined SSC mode) in response to the second required continuity type not matching (i.e. determined SSC mode being different) the continuity type of the established PDU session)
Salkintzis teaches mapping information between different characteristics of an application and different continuity types (see ([0047] and [0053], Figure 8 and [0161]-[0167]) but does not explicitly teach the mapping information between a classification associated with the application and the SSC mode.
However, the concept of determining a session continuity type based on an application type is well known in the art. For example, in a similar field of endeavor, Moses discloses in [0079], identifying session continuity on a per-application basis. [0081], discloses an alternative embodiment, in which a client side of an IP session, for example, mobile device 102, may be configured to determine whether IP session continuity is to be guaranteed for the IP session. For example, application 147 and/or controller 145 may be configured to determine whether an IP session, which is to be initiated between mobile device 102 and server 180, is to be classified as an IP session requiring IP session continuity or as an IP session not requiring IP session continuity (i.e. SSC modes), e.g., based on the type of application 147 (i.e. classification associated with application), a type of traffic to be communicated during the IP session, and/or any other information corresponding to the IP session.
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Salkintzis to include the above limitations as suggested by Moses, as selectively providing IP session continuity based on application type reduces consumption of network resources as indicated in [0006] of Moses.
Claims 11-12 and 15-18 are rejected for having the same limitations as claim 2-3 and 6-9, respectively, except the claims are in WTRU apparatus format.
Claim(s) 4-5, 13-14 is/are rejected under 35 U.S.C. 103 as being unpatentable over Salkintzis/Moses in view of “Study on Architecture for Next Generation System – 3GPP TR 23.799 V0.5.0” (hereinafter “3GPP”)
Regarding Claim 4, Salkintzis/Moses teaches The method of claim 1, wherein
Salkintzis discloses in [0045], various types of data session continuity, but Salkintzis/Moses does not explicitly teach the determined SSC mode is one of SSC mode 1, SSC mode 2 or SSC mode 3, and wherein the SSC mode associated with the existing PDU session is one of SSC mode 1, SSC mode 2 or SSC mode 3.
However, it is well known in the art that SSC modes associated with PDU sessions may include SSC mode 1, 2, or 3. For example, in a similar field of endeavor, 3GPP discloses in Section 6.6.1.1.3, session and service continuity modes:
- SSC mode 1: The same TUPF is maintained regardless of the access technology (e.g. RATs and cells) a UE is using to access the network.
- SSC mode 2: The same TUPF is only maintained across a subset (i.e. one or more, but not all) of the access network attachment points (e.g. cells and RATs), referred to as the serving area of the TUPF. When the UE leaves the serving area of a TUPF, the UE will be served by a different TUPF suitable for the UE's new point of attachment to the network.
NOTE: The serving area of a TUPF may also be limited to a single cell only, e.g. in case of stationary UEs.
- SSC mode 3: In this mode the network allows the UE to establish an additional PDU session to the same data network (DN) before the previous PDU session is eventually terminated. When the UE requests the additional PDU session, the network selects a target TUPF suitable for the UE's new point of attachment to the network. While both PDU sessions are active, the UE either actively rebinds applications from the previous to the new PDU session, or alternatively, the UE waits for flows bound to the previous PDU connection to end. Section 6.6.1.1.4.1 further discloses when requesting a PDU session, the UE may indicate the requested session and service continuity (SSC) mode as part of the PDU session setup signaling to the network.
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Salkintzis/Moses to include the above limitations as suggested by 3GPP, as support for different levels of data session continuity allows for reducing the level of session continuity in some areas where QoE requirements are relaxed to meet deployment constraints, e.g. extreme rural deployments requiring maximal cost effectiveness and minimal energy consumption, as indicated in Section 5.6.1 of 3GPP.
Regarding Claim 5, Salkintzis/Moses/3GPP teaches The method of claim 4, wherein the SSC mode 3 allows the WTRU to establish the new PDU session before the existing PDU session is terminated. (Section 6.6.1.1.3 discloses SSC mode 3: In this mode the network allows the UE to establish an additional PDU session to the same data network (DN) before the previous PDU session is eventually terminated. When the UE requests the additional PDU session, the network selects a target TUPF suitable for the UE's new point of attachment to the network. While both PDU sessions are active, the UE either actively rebinds applications from the previous to the new PDU session, or alternatively, the UE waits for flows bound to the previous PDU connection to end.)
Examiner maintains same motivation to combine as indicated in Claim 4 above.
Claims 13-14 are rejected for having the same limitations as claim 4-5, respectively, except the claims are in WTRU apparatus format.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
US 2017/0366399 A1 to Li et al., directed to general concepts of SSC modes.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JENKEY VAN whose telephone number is (571)270-7160. The examiner can normally be reached Monday - Friday 9am - 5pm.
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, Chirag Shah can be reached at (571)272-3144. 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.
/JENKEY VAN/Primary Examiner, Art Unit 2477
Prosecution Insights