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
Status of Claims
Claims 1-21 are subject to examination.
Priority
Applicant’s claim for domestic priorities as claimed in this application under 35 U.S.C. 119(e) is acknowledged. his application is a CON of 18/150,297 01/05/2023 PAT 12160413, 18/150,297 is a CON of 16/482,013 07/30/2019 PAT 11595370.
Applicant’s claim for PCT as claimed in this application under 35 U.S.C. 371, (PCT/EP18/52065) is acknowledged.
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 claims at issue 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); and 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 a nonstatutory double patenting ground provided the reference application or patent either is shown to be commonly owned with this application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b).
The USPTO internet Web site contains terminal disclaimer forms which may be used. Please visit http://www.uspto.gov/forms/. The filing date of the application will determine what form 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 http://www.uspto.gov/patents/process/file/efs/guidance/eTD-info-I.jsp.
http://www.uspto.gov/patents/process/file/efs/guidance/eTD-info-I.jsp.
Claims 1-21 are rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1-22 of U.S. Patent No. 11595370 in view of Thiebaut et al., 20180332457.
Claim of the Patent
Claim of this application
1. A method of exchanging connection parameters using Extensible Authentication Protocol, EAP, messages, the method comprising: receiving, at a server, a first message transmitted by a user equipment, UE, wherein said first message indicates an emergency attach request; the server determining, based at least in part on said first message, that an EAP authentication of said UE cannot proceed; and the server responding to the first message, wherein the step of responding to the first message comprises: the server generating a second message, wherein said second message comprises one or more connection parameters; and the server transmitting to the UE said second message.
2. The method of claim 1, wherein said first message is an identity request response message and said second message is an emergency attach initiation message.
3. The method of claim 1, wherein said second message comprises an indication regarding an access point status for said UE, and the connection parameters indicate support for one or more connection modes.
4. The method of claim 3, wherein said indication regarding an access point status for said UE indicates that said UE is accessing a network via a trusted Wireless LAN access point.
5. The method of claim 1, wherein said first message comprises one or more of an International Mobile Subscriber Identity (IMSI) and International Mobile Equipment Identity (IMEI) value and said determining comprises determining that said IMSI is not known to said server and/or said identity message indicates that said UE does not include a UICC.
6. The method of claim 1, further comprising: the server receiving a third message, wherein said third message is a response to the second message, and wherein said response message comprises one or more connection parameters, and said connection parameters comprise information regarding a connection mode for said UE.
7. The method of claim 6, wherein said information regarding a connection mode comprises one or more of information regarding one of single-connection mode and multi-connection mode, requested PDN type, and protocol configuration options.
8. The method of claim 6, wherein said third message is an EAP response to emergency attach initiation message.
9. The method of claim 1, further comprising: the server generating a fourth message, wherein said fourth message comprises one or more connection parameters; the server transmitting to the UE said fourth message; and the server receiving from the UE a fifth message.
10. The method of claim 9, wherein said fourth message is an EAP emergency attach notification message and said fifth message is an EAP response to emergency attach notification message.
11. The method of claim 9, wherein said connection parameters of the fourth message comprise one or more of PDN type supported in a PDN connection, protocol configuration options, IPv4 address and/or IPv6 interface identifier, a trusted WLAN access gateway (TWAG) user plane MAC address, and said TWAG control plane MAC address(es).
12. The method of claim 1, wherein the server is a 3GPP Authentication, Authorization and Accounting (AAA) protocol server.
13. The method of claim 1, wherein said first message comprises an IMSI or IMEI value of said UE provided within a Network Access Identifier (NAI).
14. The method of claim 1, wherein said second message indicates a request for an IMEI of said UE and third message comprises an IMEI value of said UE based on said request.
15. The method of claim 1, wherein said transmitting of connection parameters from said server to said UE occurs without usage of a shared key with respect to said UE or said receiving connection parameters from said UE occurs without usage of a shared key with respect to said UE.
16. The method of claim 1, wherein transmitting one or more of said messages comprises: the server transmitting at least one of said messages to an authenticator in communication with said server and said UE, wherein said authenticator is configured to forward said at least one message to said UE, and wherein receiving one or more of said messages comprises: receiving at least one of said messages from an authenticator in communication with said server and said UE, wherein said authenticator is configured to forward said at least one message to said server.
17. The method of claim 1, wherein said first message from said UE is a 3GPP EAP-Response/Identity message.
18. The method of claim 1, further comprising: after performing said transmitting and receiving steps, exchanging key information with said UE.
19. The method of claim 1, wherein said messages are identifiable by one or more specific values in a Vendor-Type field of an EAP message header.
20. The method of claim 1, wherein said messages share one value in a Vendor-Type field of an EAP message header of the Expanded method and are identifiable in a sub-field in the Vendor data field of the EAP message header.
21. A server comprising at least one processor; and a memory, said memory comprising instructions executable by said at least one processor, whereby said server is configured to: receive a first message transmitted by a user equipment, UE, wherein said first message indicates an emergency attach request; determine, based at least in part on said first message, that an EAP authentication of said UE cannot proceed; and respond to the first message, wherein responding to the first message comprises: generating a second message, wherein said second message comprises one or more connection parameters; and transmitting to the UE said second message, wherein said messages are EAP messages.
22. The server of claim 21, wherein said first message is an identity request response message and said second message is an emergency attach initiation message, and wherein said second message comprises an indication regarding an access point status for said UE, and the connection parameters indicate support for one or more connection modes.
1. A method of exchanging connection parameters using Extensible Authentication Protocol (EAP) messages, the method comprising:
sending, to a server from a user equipment (UE), a first message indicating an emergency attach request; and
the UE receiving a second message from the server in response to the first message,
wherein said second message comprises one or more connection parameters and said sending and receiving is enabled without mutual authentication between the server and the UE.
2. The method of claim 1, wherein said first message is an EAP responsive identity request message.
3. The method of claim 1, wherein said second message is an EAP emergency attach initiation message and comprises an indication regarding an access point status for said UE, and the connection parameters indicate support for one or more connection modes.
4. The method of claim 1, further comprising:
the UE generating a third message, wherein said third message comprises one or more connection parameters; and
the UE transmitting said third message to the server.
5. The method of claim 4, wherein said third message is an EAP response to emergency attach initiation message and said connection parameters comprises one or more of information regarding a connection mode for said UE.
6. The method of claim 5, wherein said information comprises information regarding one of single-connection mode and multi-connection mode, requested PDN type, and protocol configuration options.
7. The method of claim 4, further comprising:
the UE receiving a fourth message from the server, wherein said fourth message comprises one or more connection parameters; and
the UE transmitting a fifth message to the server that is responsive to said fourth message.
8. The method of claim 7, wherein said connection parameters of the fourth message comprise one or more of PDN type supported in a PDN connection, protocol configuration options, IPv4 address and/or IPv6 interface identifier, a trusted WLAN access gateway (TWAG) user plane MAC address, and said TWAG control plane MAC address(es).
9. The method of claim 1, wherein the server is a 3GPP Authentication, Authorization and Accounting (AAA) protocol server.
10. The method of claim 3, wherein said indication regarding an access point status for said UE indicates that said UE is accessing a network via a trusted Wireless LAN access point.
11 The method of claim 1, wherein said first message comprises an IMSI or IMEI value of said UE.
12. The method of claim 2, wherein said first message comprises an IMSI that is not known to said server, or said identity message indicates that said UE does not include a UICC.
13. The method of claim 12, wherein said second message indicates a request for an IMEI of said VE and a third message comprises an IMEI value of said UE based on said request.
14. The method of claim 1, wherein said transmission and reception of connection parameters occurs without use of a shared key with respect to said UE.
15. The method of claim 1, wherein receiving one or more messages comprises:
the UE receiving at least one message from an authenticator in communication with said server and said UE, wherein said authenticator is configured to forward said at least one message to said UE.
16. The method of claim 4, further comprising:
after performing said transmitting and receiving steps, exchanging key information with said server.
17. The method of claim 1, wherein said messages are identifiable by one or more specific values in a Vendor-Type field of an EAP message header.
18. The method of claim 1, wherein said messages share one value in a Vendor-Type field of an EAP message header of the Expanded method and are identifiable in a sub-field in the Vendor data field of the EAP message header.
19. A user equipment (UE) configured to:
send, to a server, a first message indicating an emergency attach request; and
receive a second message from the server in response to the first message, said second message comprises one or more connection parameters wherein said messages are EAP messages and said server and said UE are not mutually authenticated.
20. The VE of claim 19, wherein said first message is an EAP responsive identity request message and wherein said second message is an EAP emergency attach initiation message that comprises an indication regarding an access point status for said UE, and the connection parameters indicate support for one or more connection modes.
21. A user equipment (UE) for communicating with a server, comprising:
a receiving module, configured to receive, at said UE from said server, one or more emergency attach identity message, emergency attach initiation message, and emergency attach notification message comprising one or more connection parameters; and
a transmitting module, configured to transmit, from said UE to said server, one or more of a responsive emergency attach identity message, a responsive emergency attach initiation message, and a responsive emergency attach notification message comprising one or more connection parameters,
wherein said messages are EAP messages and said server and said UE are not mutually authenticated.
The patent claims do not contain, without mutual authentication between the server and the UE, which is well-known and expected in the art.
Thiebaut discloses, a connection parameter, EAP messages and without mutual authentication,
[0050] a specific EAP procedure for access to emergency services without authentication is run to allow the UE and the network to exchange parameters they exchange via EAP-AKA′ in case of a regular authentication (e.g. request from the UE for an IP version in SCM; TWAN control plane address in MCM). This procedure reuses EAP-AKA′ but modifies it as there is no mutual authentication between the UE and the network. It nevertheless reuses all the mechanisms defined so far in EAP-AKA′ to negotiate between the UE and the network the TWAN mode (SCM/MCM) as well as to negotiate the parameters of the PDN connection in SCM [0051] in both Single-Connection Mode (SCM) and Multiple-Connection Mode (MCM), the UE also includes a new Emergency-Indication information to indicate to the AAA Server the establishment of an emergency PDN connection in the EAP-AKA′ (this indication is already mentioned in 3GPP TR 23.771 for the case of a regular authentication but its inclusion as part of EAP-AKA′ is part of embodiments of the invention). For a trusted WLAN access in Multiple-Connection Mode (MCM), the UE also includes a new Emergency Indication (already mentioned in 3GPP TR 23.771) as part of the WLCP PDN connection request following the attachment to the network, para 87-93
Therefore, it would have been obvious to one of ordinary skill in the art at the time of the effective filing date of the claimed invention to include these limitations and also one of ordinary skill in the art would have been motivated to do so because it could provide utilizing connection parameter for negotiation among devices and establish a connection between the devices. This would allow UE and another device on network to communicate avoiding mutual authentication, para 50, 51.
“A later patent claim is not patentably distinct from an earlier patent claim if the later claim is obvious over, or anticipated by, the earlier claim”.
In re Longi, 759 F.2d at 896, 225 USPQ at 651 (affirming a holding of obviousness-type double patenting because the claims at issue were obvious over claims in four prior art patents); In re Bern, 140 F.3d at 1437, 46 USPQ2d at 1233 (Fed. Cir. 1998) (affirming a holding of obviousness-type double patenting where a patent application claim to a genus is anticipated by a patent claim to a species within that genus). '' ELI LILLY AND COMPANY v BARR LABORATORIES, INC., United States Court of Appeals for the Federal Circuit, ON PETITION FOR REHEARING EN BANC (DECIDED: May 30, 2001).
Specification
In paragraph [0001], status of co-pending applications should be made with --now copending-- and status of patent applications should be --now U.S. Patent number --.
Drawings
The figures submitted on the filing date of this application are acknowledged.
Information Disclosure Statement
An initialed and dated copy of the applicant’s IDS form 1449 (dated 1/5/23), is attached to the instant Office action.
Claim Limitation Interpreted under 35 U.S.C. 112(f) or
pre-AIA 35 USC § 112, Sixth Paragraph
The following is a quotation of 35 U.S.C. 112(f):
(f) Element in Claim for a Combination. – An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The following is a quotation of pre-AIA 35 U.S.C. 112, sixth paragraph:
An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The claims in this application are given their broadest reasonable interpretation using the plain meaning of the claim language in light of the specification as it would be understood by one of ordinary skill in the art. The broadest reasonable interpretation of a claim element (also commonly referred to as a claim limitation) is limited by the description in the specification when 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is invoked.
As explained in MPEP § 2181, subsection I, claim limitations that meet the following three-prong test will be interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph:
(A) the claim limitation uses the term “means” or “step” or a term used as a substitute for “means” that is a generic placeholder (also called a nonce term or a non-structural term having no specific structural meaning) for performing the claimed function;
(B) the term “means” or “step” or the generic placeholder is modified by functional language, typically, but not always linked by the transition word “for” (e.g., “means for”) or another linking word or phrase, such as “configured to” or “so that”; and
(C) the term “means” or “step” or the generic placeholder is not modified by sufficient structure, material, or acts for performing the claimed function.
Use of the word “means” (or “step”) in a claim with functional language creates a rebuttable presumption that the claim limitation is to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites sufficient structure, material, or acts to entirely perform the recited function.
Absence of the word “means” (or “step”) in a claim creates a rebuttable presumption that the claim limitation is not to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is not interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites function without reciting sufficient structure, material or acts to entirely perform the recited function.
Claim limitations in this application that use the word “means” (or “step”) are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action. Conversely, claim limitations in this application that do not use the word “means” (or “step”) are not being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action.
This application includes one or more claim limitations that do not use the word “means,” but are nonetheless being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, because the claim limitation(s) uses a generic placeholder that is coupled with functional language without reciting sufficient structure to perform the recited function and the generic placeholder is not preceded by a structural modifier. Such claim limitation(s) is/are: “receiving module configured to receive”, “transmitting module configured to receive”.
Because this/these claim limitation(s) is/are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, it/they is/are being interpreted to cover the corresponding structure described in the specification as performing the claimed function, and equivalents thereof.
If applicant does not intend to have this/these limitation(s) interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, applicant may: (1) amend the claim limitation(s) to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph (e.g., by reciting sufficient structure to perform the claimed function); or (2) present a sufficient showing that the claim limitation(s) recite(s) sufficient structure to perform the claimed function so as to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 1-19, 21, are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as failing to set forth the subject matter which the inventor or a joint inventor, or for applications subject to pre-AIA 35 U.S.C. 112, the applicant regards as the invention. Evidence that claims 1-21 fail(s) to correspond in scope with that which the inventor or a joint inventor, or for pre-AIA applications the applicant regards as the invention can be found in the preamble of claim 1, “a method of exchanging connection parameters using Extensible Authentication Protocol (EAP) messages”. In the preamble, the inventor or a joint inventor, or for pre-AIA applications the applicant has stated “a method of exchanging connection parameters using Extensible Authentication Protocol (EAP) messages”, and this statement indicates that the invention is different from what is defined in the claim(s) because the body of the claim do not accomplish “a method of exchanging connection parameters using Extensible Authentication Protocol (EAP) messages”. The claimed sending and receiving steps are not limited to “exchanging connection parameters using Extensible Authentication Protocol (EAP) messages”. Removal of “exchanging connection parameters using Extensible Authentication Protocol (EAP) messages” from the preamble of claim 1 (similar to claims 19 and 21), or addition of -- step that is exchanging connection parameters using Extensible Authentication Protocol (EAP) messages – in the body of the claim 1 is suggested to overcome the rejections.
Claim 21 contains, “a transmitting module, configured to transmit, from said UE to said server, one or more of a responsive emergency attach identity message, a responsive emergency attach initiation message, and a responsive emergency attach notification message comprising one or more connection parameters”,
The term “responsive”(s) in claim 21 is a relative term which renders the claim indefinite. One of ordinary skill in the art would not be reasonably apprised of the scope of the invention. The receiving module if receives emergency attach notification message, the transmitting module merely sends a message to the server, which is not in response to the received emergency attach notification message. The “responsive” is a relative term because it is not in response to anything and it is not different than a “emergency attach notification message”. All the claimed “responsive” messages are same, and similar to the received messages. Mere labelling with “responsive” would not make the message different than others.
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 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 of this title, 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.
Claim(s) 1, 9, 14, 21 is/are rejected under 35 U.S.C. 103 as being unpatentable over RYU et al., 20190342940 in view of Thiebaut et al., 20180332457.
Referring to claim(s) 1, 19, Ryu discloses UE configured to, a method of exchanging connection parameters using Extensible Authentication Protocol (EAP) messages, the method comprising: sending, to a server from a user equipment (UE), a first message indicating an emergency attach request; and
[0253] In contrast, when the UE initiates an Attach procedure for an emergency bearer service, the UE indicates “EPS emergency Attach” in the EPS Attach type information element (IE) within the ATTACH REQUEST message.
the UE receiving a second message from the server in response to the first message, wherein said second message comprises information and
[0254] When the Attach request is accepted by a network, the MME transmits an ATTACH ACCEPT message to the UE as a response to the ATTACH REQUEST message (S1102).
[0255] If the Attach request has included a PDN CONNECTIVITY REQUEST message for requesting a PDN connection, when the MME accepts the Attach request, the MME transmits an ACTIVATE DEFAULT EPS BEARER CONTEXT REQUEST message to the UE along with the ATTACH ACCEPT message in order to activate a default EPS bearer.
said sending and receiving is enabled between the server and the UE (para 253-254).
Ryu does not specifically mention about, which is well-known in the art, which Thiebaut discloses, a connection parameter, EAP messages and without mutual authentication,
[0050] a specific EAP procedure for access to emergency services without authentication is run to allow the UE and the network to exchange parameters they exchange via EAP-AKA′ in case of a regular authentication (e.g. request from the UE for an IP version in SCM; TWAN control plane address in MCM). This procedure reuses EAP-AKA′ but modifies it as there is no mutual authentication between the UE and the network. It nevertheless reuses all the mechanisms defined so far in EAP-AKA′ to negotiate between the UE and the network the TWAN mode (SCM/MCM) as well as to negotiate the parameters of the PDN connection in SCM [0051] in both Single-Connection Mode (SCM) and Multiple-Connection Mode (MCM), the UE also includes a new Emergency-Indication information to indicate to the AAA Server the establishment of an emergency PDN connection in the EAP-AKA′ (this indication is already mentioned in 3GPP TR 23.771 for the case of a regular authentication but its inclusion as part of EAP-AKA′ is part of embodiments of the invention). For a trusted WLAN access in Multiple-Connection Mode (MCM), the UE also includes a new Emergency Indication (already mentioned in 3GPP TR 23.771) as part of the WLCP PDN connection request following the attachment to the network, para 87-93
Therefore, it would have been obvious to one of ordinary skill in the art at the time of the effective filing date of the claimed invention to modify the invention disclosed by Ryu to implement these limitations and also one of ordinary skill in the art would have been motivated to do so because it could provide utilizing connection parameter for negotiation among devices and establish a connection between the devices. This would allow UE and another device on network to communicate avoiding mutual authentication, para 50, 51.
Referring to claim(s) 9, Thiebaut discloses wherein the server is a 3GPP Authentication, Authorization and Accounting (AAA) protocol server, para 91
[0051] in both Single-Connection Mode (SCM) and Multiple-Connection Mode (MCM), the UE also includes a new Emergency-Indication information to indicate to the AAA Server the establishment of an emergency PDN connection in the EAP-AKA′ (this indication is already mentioned in 3GPP TR 23.771 for the case of a regular authentication but its inclusion as part of EAP-AKA′ is part of embodiments of the invention). For a trusted WLAN access in Multiple-Connection Mode (MCM), the UE also includes a new Emergency Indication (already mentioned in 3GPP TR 23.771) as part of the WLCP PDN connection request following the attachment to the network.
Referring to claim(s) 14, Ryu and Thiebaut wherein said transmission and reception of connection parameters occurs without use of a shared key with respect to said UE (without shared key, Ryu, para 253, Thiebaut, para 50, 51).
Claim(s) 2, Is/are rejected under 35 U.S.C. 103 as being unpatentable over RYU in view of Thiebaut and FORSSELL et al., 20170264606.
Referring to claim(s) 2, Ryu and Thiebaut do not disclose wherein said first message is an EAP responsive identity request message, which is well-known in the art, which Forssell discloses,
[0121] In certain embodiments, a HetNet user/UE identity may correspond to a radius user name During WLAN hotspot authentication, the UE may identify itself to the AAA server in an EAP-Identity/Response message by providing a username@realm, for example, john.smith@mcc.mnc.3gpp.com. In this example, “John Smith” may be a username, and an MCC (mobile country code) and an MNC (mobile network code) may identify a country and a network operator, respectively. The UE may provide a used WLAN username@realm identity to RAN within a RRC message. The RAN and WLAN networks may exchange user/UE related messages by using the identity. [0140] In certain embodiments of the present invention, an authentication request from the UE will then be forwarded to the AAA server based on the used realm in the identity. The AAA may not know this PTID, but the AAA may explicitly inquire the proper EAP-SIM/AKA identity from the UE. The AAA may inquire the identity using an EAP-Identity Request message (such an inquiry is in accordance with the current standards when an anonymous identification is used). Such an inquiry allows the AAA to properly authenticate the user. The WLAN AP may continue to use an original PTID in Radius messages as an outer user identity in all AAA communication. In certain embodiments, the IMSI may possibly not be revealed to any party of the communication, and the IMSI may not be required by any party. The RAN and WLAN network may communicate using this PTID identity as UE identification.
Therefore, it would have been obvious to one of ordinary skill in the art at the time of the effective filing date of the claimed invention to modify the invention disclosed by Ryu to implement these limitations and also one of ordinary skill in the art would have been motivated to do so because it could provide utilizing identity request message, The identity would be provided by the device, which would allow the requesting entity to verify the identification, para 50, 51.
Claim(s) 17, Is/are rejected under 35 U.S.C. 103 as being unpatentable over RYU in view of Thiebaut and Goodall et al., 7683773.
Referring to claim(s) 17, Ryu and Thiebaut do not disclose wherein said messages are identifiable by one or more specific values in a Vendor-Type field of an EAP message header, which is well-known in the art, which Goodall discloses,
One such available field is the type field in the EAP packet header. EAP-TLS may be adapted to carrying telemetry data by changing the type field value in each EAP-TLS EAP packet header from the value for EAP-TLS (13) to the value for an Expanded Type (254). The RADIUS server can then determine that the EAP packets should be sent to the software module that deals with telemetry data by looking at the additional vendor ID and vendor type fields that occur in an Expanded Type EAP frame. In the event that different tags encapsulate telemetry data in different ways, the particular approach used by a particular tag may be determined by looking at the vendor ID and vendor type. Some existing EAP methods such as EAP-FAST can be adapted more easily to carrying telemetry data because they already support transmission of data in TLV (type, length, value) fields. Col., 8, lines 45 – 58.
Therefore, it would have been obvious to one of ordinary skill in the art at the time of the effective filing date of the claimed invention to modify the invention disclosed by Ryu to implement these limitations and also one of ordinary skill in the art would have been motivated to do so because it could provide utilizing Vendor-Type field of an EAP message header. The server would be able to determine that the EAP packets should be sent to the software module that deals with telemetry data, based on the field value, col., 8, lines 45 – 58.
Claim(s) 15, Is/are rejected under 35 U.S.C. 103 as being unpatentable over RYU in view of Thiebaut and JOHN KAIPPALLIMALIL VN 10030329 B.
Referring to claim(s) 15, Ryu and Thiebaut do not disclose the UE receiving a message from an authenticator in communication with said server and said UE, wherein said authenticator is configured to forward said message to said UE, which is well-known in the art, which John discloses,
With respect to connection release and detach flow sequence, FIG. 6 illustrates an embodiment method 600 for a UE in a N3GPP network to release a connection or detach. In an embodiment, unless otherwise stated, UE 602, AP 604, TWAG 606, PDN GW 608, visited Policy and Charging Rule Function (vPCRF) 610, AAA Proxy 612, home Policy and Charging Rule Function (hPCRF) 614, and home subscriber server (HSS)/AAA 616 may be similar to similar components and function in a similar manner to similar components described in FIGS. 5A & 5B. The vPCRF 610 and the hPCRF 614 are used for center control of QoS and charging policy. The AAA proxy is used in the roaming case to forward authentication messages between the UE and the AAA server (in home network) in visited network. The HSS stores user subscriber data in the home network and may send the data to the AAA server when requested. The following sequence of steps is used to release a PDN access connection or detach completely, sixty para, page 8.
Therefore, it would have been obvious to one of ordinary skill in the art at the time of the effective filing date of the claimed invention to modify the invention disclosed by Ryu to implement these limitations and also one of ordinary skill in the art would have been motivated to do so because it could provide utilizing the authenticator to forward the message. The well-known device/software would be able to forward authentication messages between the UE and the server, col., 8, lines 45 – 58.
Claim(s) 3, Is/are rejected under 35 U.S.C. 103 as being unpatentable over RYU in view of Thiebaut, GUPTA, WO 2014107358 A1, Xi, CN 101500214 B and JP 2018537927 A.
Referring to claim(s) 3, EAP emergency attach (response to the emergency attach request) is rejected in claim 1. Ryu and Thiebaut do not disclose wherein said second message is an attach initiation message, which is well-known in the art, which Gupta discloses,
Figure 4 shows a UE 410 performing an authentication with a network/EAP server 450. Figure 4 has been simplified for illustrative purposes and does not show an EAP authenticator (WLAN access point). The EAP authenticator (not shown) acts as an intermediary for EAP message exchange between the UE (EAP peer) 410 and the EAP server (3GPP AAA Server) 450. As shown in Figure 4, an EAP Request message 412 and an EAP response message 414 that are communicated between the UE 410 and the EAP server 450 are configured to carry attach parameters comprising an APN parameter, an NSWO parameter and an HO (handover) parameter, second last para, page 7
Therefore, it would have been obvious to one of ordinary skill in the art at the time of the effective filing date of the claimed invention to modify the invention disclosed by Ryu to implement these limitations and also one of ordinary skill in the art would have been motivated to do so because it could provide utilizing message that would carry parameters to accomplish attach of the device. The communication of the messages between the EPA server and the EPA client would carry APN associated information for implementation, second last para, page 7. Ryu, Gupta, and Thiebaut do not disclose an indication regarding an access point status for said UE, which is well-known in the art, which Xi discloses, para 113, 68. Therefore, it would have been obvious to one of ordinary skill in the art at the time of the effective filing date of the claimed invention to modify the invention disclosed by Ryu to implement these limitations and also one of ordinary skill in the art would have been motivated to do so because it could provide utilizing the information about the access point. The information of the EAP message would enable establish a connection with the user device, para 113, 68.
Ryu, Gupta, Xi and Thiebaut do not disclose connection parameters indicate support for one or more connection modes, which is well-known in the art, which JP 2018537927 A discloses,
The 6.3GPP AAA server sends an EAP request / AKA 'challenge, where the 3GPP AAA server sends a TWAN connection mode (eg, TSCM, SCM and MCM) supported by the network, which is unauthenticated, Indicates to the UE that the access is for a limited service . The result code AVP in the DEA message is set to DIAMETER_MULTI_ROUND_AUTH. The TWAN-S2a connectivity indicator is not set in the DEA flag AVP. The DEA message also contains an indication that this is access for limited services without authentication, fifth para, page 7
Therefore, it would have been obvious to one of ordinary skill in the art at the time of the effective filing date of the claimed invention to modify the invention disclosed by Ryu to implement these limitations and also one of ordinary skill in the art would have been motivated to do so because it could provide utilizing the connection mode. A single connection mode or a multi-connection mode would be specified by the parameter sent by the server. This would enable implementing a desired connection mode among the modes for further communication, fifth para, page 7.
Claim(s) 11, Is/are rejected under 35 U.S.C. 103 as being unpatentable over RYU in view of Thiebaut and Li, et al., 20170156043.
Referring to claim(s) 11, Ryu and Thiebaut do not disclose wherein said first message comprises an IMSI or IMEI value of said UE, which is well-known in the art, which Li discloses,
[0027] Wireless device 175 transmits an emergency attach request to MME 120-2 (illustrated as emergency attach 221). The emergency attach request includes the IMEI of wireless device 175. The emergency attach request may also include the IMSI. As further illustrated, MME 120-2 selects a PGW so that an emergency bearer can be established (illustrated as selects PGW 223). For example, MME 120-2 selects PGW 115-2.
Therefore, it would have been obvious to one of ordinary skill in the art at the time of the effective filing date of the claimed invention to modify the invention disclosed by Ryu to implement these limitations and also one of ordinary skill in the art would have been motivated to do so because it could provide utilizing IMSI/IMEI information associated with a device. The IMSI/IMEI information would be sent from the device, which would enable performing an emergency attach for the device, para 27.
Claim(s) 18, Is/are rejected under 35 U.S.C. 103 as being unpatentable over RYU in view of Thiebaut, Goodall and Huang et al., 20130051303.
Referring to claim(s) 18, Ryu and Thiebaut do not disclose wherein said messages share one value in a Vendor-Type field of an EAP message header of the Expanded method, which is well-known in the art, which Goodall discloses,
One such available field is the type field in the EAP packet header. EAP-TLS may be adapted to carrying telemetry data by changing the type field value in each EAP-TLS EAP packet header from the value for EAP-TLS (13) to the value for an Expanded Type (254). The RADIUS server can then determine that the EAP packets should be sent to the software module that deals with telemetry data by looking at the additional vendor ID and vendor type fields that occur in an Expanded Type EAP frame. In the event that different tags encapsulate telemetry data in different ways, the particular approach used by a particular tag may be determined by looking at the vendor ID and vendor type. Some existing EAP methods such as EAP-FAST can be adapted more easily to carrying telemetry data because they already support transmission of data in TLV (type, length, value) fields. Col., 8, lines 45 – 58.
Therefore, it would have been obvious to one of ordinary skill in the art at the time of the effective filing date of the claimed invention to modify the invention disclosed by Ryu to implement these limitations and also one of ordinary skill in the art would have been motivated to do so because it could provide utilizing sharing value of Vendor-Type field of an EAP message header. The server would be able to determine that the EAP packets should be sent to the software module that deals with telemetry data, based on the field value, col., 8, lines 45 – 58.
Ryu, Goodall and Thiebaut do not disclose identifiable in a sub-field in the data field of the EAP message header, which is well-known in the art, which Huang discloses (table 3),
Therefore, it would have been obvious to one of ordinary skill in the art at the time of the effective filing date of the claimed invention to modify the invention disclosed by Ryu to implement these limitations and also one of ordinary skill in the art would have been motivated to do so because it could provide utilizing sub-field in the data field of the EAP message header. The server would be able to determine that the EAP packets should be sent to the software module that deals with telemetry data, based on the sub field value, table 3.
Claim(s) 10, Is/are rejected under 35 U.S.C. 103 as being unpatentable over RYU in view of Thiebaut, GUPTA, Xi, and JP 2018537927 A.
Referring to claim(s) 10, Xi discloses wherein said indication regarding an access point status for said UE indicates that said UE is accessing a network (para 113, 68) via a trusted Wireless LAN access point (Thiebaut, para 59, 52).
Claim(s) 18, Is/are rejected under 35 U.S.C. 103 as being unpatentable over RYU in view of Thiebaut, Goodall and Choyi et al., 20140050320.
Referring to claim(s) 18, Ryu and Thiebaut do not disclose wherein said messages share one value in a Vendor-Type field of an EAP message header of the Expanded method, which is well-known in the art, which Goodall discloses,
One such available field is the type field in the EAP packet header. EAP-TLS may be adapted to carrying telemetry data by changing the type field value in each EAP-TLS EAP packet header from the value for EAP-TLS (13) to the value for an Expanded Type (254). The RADIUS server can then determine that the EAP packets should be sent to the software module that deals with telemetry data by looking at the additional vendor ID and vendor type fields that occur in an Expanded Type EAP frame. In the event that different tags encapsulate telemetry data in different ways, the particular approach used by a particular tag may be determined by looking at the vendor ID and vendor type. Some existing EAP methods such as EAP-FAST can be adapted more easily to carrying telemetry data because they already support transmission of data in TLV (type, length, value) fields. Col., 8, lines 45 – 58.
Therefore, it would have been obvious to one of ordinary skill in the art at the time of the effective filing date of the claimed invention to modify the invention disclosed by Ryu to implement these limitations and also one of ordinary skill in the art would have been motivated to do so because it could provide utilizing sharing value of Vendor-Type field of an EAP message header. The server would be able to determine that the EAP packets should be sent to the software module that deals with telemetry data, based on the field value, col., 8, lines 45 – 58.
Ryu, Huang and Thiebaut do not disclose identifiable in a sub-field in the data field of the EAP message header, which is well-known in the art, which Choyi discloses (para 413),
Therefore, it would have been obvious to one of ordinary skill in the art at the time of the effective filing date of the claimed invention to modify the invention disclosed by Ryu to implement these limitations and also one of ordinary skill in the art would have been motivated to do so because it could provide utilizing sub-field in the data field of the EAP message header. The server would be able to determine that the EAP packets should be sent to the software module that deals with telemetry data, based on the sub field value, para 413.
Claim(s) 12, Is/are rejected under 35 U.S.C. 103 as being unpatentable over RYU in view of Thiebaut, Li, and Shan et al., 20180295659.
Referring to claim(s) 12, Li discloses, wherein said first message comprises an IMSI or said identity message indicates that said UE does not include a UICC
[0027] Wireless device 175 transmits an emergency attach request to MME 120-2 (illustrated as emergency attach 221). The emergency attach request includes the IMEI of wireless device 175. The emergency attach request may also include the IMSI. As further illustrated, MME 120-2 selects a PGW so that an emergency bearer can be established (illustrated as selects PGW 223). For example, MME 120-2 selects PGW 115-2.
Li, Ryu and Thiebaut do not disclose IMSI that is not known to said server, which is well-known in the art, which Shan discloses, para 44,
Therefore, it would have been obvious to one of ordinary skill in the art at the time of the effective filing date of the claimed invention to modify the invention disclosed by Ryu to implement these limitations and also one of ordinary skill in the art would have been motivated to do so because it could provide utilizing IMSI information associated with a device. The IMSI information would be sent from the device, which would enable performing an emergency attach for the device, Shan para 44, Li, para 27.
Claim(s) 13, Is/are rejected under 35 U.S.C. 103 as being unpatentable over RYU in view of Thiebaut, Li, Shan and Drevon et al., 20180317087.
Referring to claim(s) 13, Li, Ryu, Shan and Thiebaut do not disclose a request for an IMEI of said UE and a third message comprises an IMEI value of said UE based on said request, which Drevon discloses (AAA server requests IMEI from the UE for the emergency session, para 56). Therefore, it would have been obvious to one of ordinary skill in the art at the time of the effective filing date of the claimed invention to modify the invention disclosed by Ryu to implement these limitations and also one of ordinary skill in the art would have been motivated to do so because it could provide utilizing communicating of messages between a server and a device. The messages would enable requesting of an IMEI information associated with a device. The response of the request would enable providing of the IMSI information associated with the device for establishing an emergency session, Drevon para 56.
Claim(s) 4, Is/are rejected under 35 U.S.C. 103 as being unpatentable over RYU in view of Thiebaut, and VALLABHU et al. 20160183313.
Referring to claim(s) 4, Thiebaut, Ryu, do not disclose, which is well-known in the art, which Vallabhu discloses, the UE generating a third message, wherein said third message comprises one or more connection parameters; the UE transmitting said third message to the server (additional exchanged information, PDN Type, APN, other attachment parameters, para 72). Therefore, it would have been obvious to one of ordinary skill in the art at the time of the effective filing date of the claimed invention to modify the invention disclosed by Ryu to implement these limitations and also one of ordinary skill in the art would have been motivated to do so because it could provide utilizing exchanging of addition information using message between a server and a device. The messages would enable requesting further information such as PDN Type, etc.. The response of the request would enable providing of the PDN type information associated with the device/server for establishing an PDN connection, para 72.
Claim(s) 5, Is/are rejected under 35 U.S.C. 103 as being unpatentable over RYU in view of Thiebaut, VALLABHU and JOHN MATHEW et al., EP 3336711 B1.
Referring to claim(s) 5, Ryu discloses emergency attach initiation message as rejected in claim 1. Thiebaut discloses wherein said message is an EAP response to emergency attach initiation message, para 93. Thiebaut, Ryu, VALLABHU do not disclose, which is well-known in the art, which John Mathew discloses, wherein said third message is an EAP response and said connection parameters comprises one or more of information regarding a connection mode for said UE (receiving a request for multi-connection mode from the UE. Embodiment 3. The method according to embodiment 1, further comprising receiving via WLCP a packet data network (PDN) connection request from the UE, Last para, page 11).Therefore, it would have been obvious to one of ordinary skill in the art at the time of the effective filing date of the claimed invention to modify the invention disclosed by Ryu to implement these limitations and also one of ordinary skill in the art would have been motivated to do so because it could provide utilizing message for communicating connection mode regarding the device. The communication mode information would enable specifying the type of communication mode such as multi connection mode, Last para, page 11.
Claim(s) 6, Is/are rejected under 35 U.S.C. 103 as being unpatentable over RYU in view of Thiebaut, VALLABHU, JOHN MATHEW and KR 101589574 B1.
Referring to claim(s) 6, John Mathew discloses multi-connection mode, Last para, page 11. VALLABHU discloses requested PDN type, para 72. Li, Ryu, VALLABHU, John Mathew do not disclose, which is well-known in the art, which KR 101589574 B1 discloses, protocol configuration options (when the UE is attached to a 3GPP access network, protocol configuration options (PCO) information elements that can be used to convey user credentials between the UE and the core network are specified. User credentials are, for example, user names and user passwords within PAP or CHAP parameters (PAP: password authentication protocol, CHAP: challenge-handshake protocol, para first, page 4).Therefore, it would have been obvious to one of ordinary skill in the art at the time of the effective filing date of the claimed invention to modify the invention disclosed by Ryu to implement these limitations and also one of ordinary skill in the art would have been motivated to do so because it could provide utilizing well-known PCO. When the UE is attached to a network, protocol configuration options (PCO) information elements that can be used to convey user credentials such as user names and user passwords within PAP or CHAP parameters, between the UE and the network would be specified, para first, page 4.
Claim(s) 7, Is/are rejected under 35 U.S.C. 103 as being unpatentable over RYU in view of Thiebaut, VALLABHU and KR 101589574 B1.
Referring to claim(s) 7, Li, Ryu, VALLABHU do not disclose, which is well-known in the art, which KR 101589574 B1 discloses, the UE receiving a fourth message from the server, wherein said fourth message comprises one or more connection parameters; and the UE transmitting a fifth message to the server that is responsive to said fourth message (when the UE is attached to a 3GPP access network, protocol configuration options (PCO) information elements that can be used to convey user credentials between the UE and the core network are specified. User credentials are, for example, user names and user passwords within PAP or CHAP parameters (PAP: password authentication protocol, CHAP: challenge-handshake protocol), first para, page 4). Therefore, it would have been obvious to one of ordinary skill in the art at the time of the effective filing date of the claimed invention to modify the invention disclosed by Ryu to implement these limitations and also one of ordinary skill in the art would have been motivated to do so because it could provide utilizing well-known further receiving of connection parameter and a response. When the UE is attached to a network, protocol configuration options (PCO) information elements that can be used to convey user credentials such as user names and user passwords within PAP or CHAP parameters, between the UE and the network would be specified, para first, page 4.
Claim(s) 17, Is/are rejected under 35 U.S.C. 103 as being unpatentable over RYU in view of Thiebaut and Chin et al., 20160183156.
Referring to claim(s) 17, Ryu and Thiebaut do not disclose wherein said messages are identifiable by one or more specific values in a Vendor-Type field of an EAP message header, which is well-known in the art, which Chi discloses, para 1108.
Therefore, it would have been obvious to one of ordinary skill in the art at the time of the effective filing date of the claimed invention to modify the invention disclosed by Ryu to implement these limitations and also one of ordinary skill in the art would have been motivated to do so because it could provide utilizing Vendor-Type field of an EAP message header. The server would be able to determine that the EAP packets should be sent to the software module that deals with telemetry data, based on the field value, col., 8, lines 45 – 58.
Claim(s) 8, Is/are rejected under 35 U.S.C. 103 as being unpatentable over RYU in view of Thiebaut, VALLABHU, KR 101589574 B1 and Li et al., WO 2017053742 A1.
Referring to claim(s) 8, KR 101589574 B1 discloses PCO, para first, page 4. Li, Ryu, VALLABHU, KR 101589574 B1 do not disclose, which is well-known in the art, which Li discloses, PDN TYPE, TWAG user plane MAC addresses, TWAG control plane MAC addresses (para 74, 130), IPV4/IPV6 address (para 20, 21, 131). Therefore, it would have been obvious to one of ordinary skill in the art at the time of the effective filing date of the claimed invention to modify the invention disclosed by Ryu to implement these limitations and also one of ordinary skill in the art would have been motivated to do so because it could provide utilizing well-known connection parameter and a response. When the UE is attached to a network, connection parameters that can be used to establish connections would be specified and communicated across network. The parameters would enable configuring the connections, para 74, 130,21.
Claim(s) 15, Is/are rejected under 35 U.S.C. 103 as being unpatentable over RYU in view of Thiebaut and Sharaga et al., 2016/0182499.
Referring to claim(s) 15, Ryu and Thiebaut do not disclose the UE receiving a message from an authenticator in communication with said server and said UE, wherein said authenticator is configured to forward said message to said UE, which is well-known in the art, which Sharaga discloses,
(authenticator between the UE and the server for forwarding messages, para 46, figure 3). Therefore, it would have been obvious to one of ordinary skill in the art at the time of the effective filing date of the claimed invention to modify the invention disclosed by Ryu to implement these limitations and also one of ordinary skill in the art would have been motivated to do so because it could provide utilizing the authenticator to forward the message. The well-known device/software would be able to forward authentication messages between the UE and the server, para 46, figure 3.
Claim(s) 21 is/are rejected under 35 U.S.C. 103 as being unpatentable over Gupta in view of VALLABHU and Thiebaut.
Referring to claim(s) 21, Gupta discloses UE for communicating with a server
a receiving module, configured to receive, at said UE from said server, one or more emergency attach identity message, emergency attach initiation message, and emergency attach notification message comprising one or more connection parameters, wherein said message is EAP message
Figure 4 shows a UE 410 performing an authentication with a network/EAP server 450. Figure 4 has been simplified for illustrative purposes and does not show an EAP authenticator (WLAN access point). The EAP authenticator (not shown) acts as an intermediary for EAP message exchange between the UE (EAP peer) 410 and the EAP server (3GPP AAA Server) 450. As shown in Figure 4, an EAP Request message 412 and an EAP response message 414 that are communicated between the UE 410 and the EAP server 450 are configured to carry attach parameters comprising an APN parameter, an NSWO parameter and an HO (handover) parameter, second last para, page 7
VALLABHU discloses a transmitting module, configured to transmit, from said UE to said server, one or more of a responsive emergency attach identity message, a responsive emergency attach initiation message, and a responsive emergency attach notification message comprising one or more connection parameters, wherein said message is EAP message (EAP, additional exchanged information, PDN Type, APN, and other attachment parameters, para 72). Therefore, it would have been obvious to one of ordinary skill in the art at the time of the effective filing date of the claimed invention to modify the invention disclosed by Gupta to implement these limitations and also one of ordinary skill in the art would have been motivated to do so because it could provide utilizing exchanging of addition information using message between a server and a device. The messages would enable requesting further information such as PDN Type, etc. The response of the request would enable providing of the PDN type information associated with the device/server for establishing an PDN connection, para 72.
Gupta, and VALLABHU does not specifically mention about, which is well-known in the art, which Thiebaut discloses, a said server and said UE are not mutually authenticated,
[0050] a specific EAP procedure for access to emergency services without authentication is run to allow the UE and the network to exchange parameters they exchange via EAP-AKA′ in case of a regular authentication (e.g. request from the UE for an IP version in SCM; TWAN control plane address in MCM). This procedure reuses EAP-AKA′ but modifies it as there is no mutual authentication between the UE and the network. It nevertheless reuses all the mechanisms defined so far in EAP-AKA′ to negotiate between the UE and the network the TWAN mode (SCM/MCM) as well as to negotiate the parameters of the PDN connection in SCM [0051] in both Single-Connection Mode (SCM) and Multiple-Connection Mode (MCM), the UE also includes a new Emergency-Indication information to indicate to the AAA Server the establishment of an emergency PDN connection in the EAP-AKA′ (this indication is already mentioned in 3GPP TR 23.771 for the case of a regular authentication but its inclusion as part of EAP-AKA′ is part of embodiments of the invention). For a trusted WLAN access in Multiple-Connection Mode (MCM), the UE also includes a new Emergency Indication (already mentioned in 3GPP TR 23.771) as part of the WLCP PDN connection request following the attachment to the network.
Therefore, it would have been obvious to one of ordinary skill in the art at the time of the effective filing date of the claimed invention to modify the invention disclosed by Ryu to implement these limitations and also one of ordinary skill in the art would have been motivated to do so because it could provide utilizing connection parameter for negotiation among devices and establish a connection between the devices. This would allow UE and another device on network to communicate avoiding mutual authentication, para 50, 51.
Claim(s) 18, Is/are rejected under 35 U.S.C. 103 as being unpatentable over RYU in view of Thiebaut, Chin and Knowles 20150271745.
Referring to claim(s) 18, Ryu and Thiebaut do not disclose wherein said messages share one value in a Vendor-Type field of an EAP message header of the Expanded method, which is well-known in the art, which Chin discloses, para 1108. Therefore, it would have been obvious to one of ordinary skill in the art at the time of the effective filing date of the claimed invention to modify the invention disclosed by Ryu to implement these limitations and also one of ordinary skill in the art would have been motivated to do so because it could provide utilizing sharing value of Vendor-Type field of an EAP message header. The server would be able to determine that the EAP packets should be sent to the software module that deals with telemetry data, based on the field value, para 1108.
Ryu, Chin and Thiebaut do not disclose identifiable in a sub-field in the data field of the EAP message header, which is well-known in the art, which Knowles discloses, para 91, figure 9.
Therefore, it would have been obvious to one of ordinary skill in the art at the time of the effective filing date of the claimed invention to modify the invention disclosed by Ryu to implement these limitations and also one of ordinary skill in the art would have been motivated to do so because it could provide utilizing sub-field in the data field of the EAP message header. The server would be able to determine that the EAP packets should be sent to the software module that deals with telemetry data, based on the sub field value, para 91, figure 9.
Claim(s) 20, Is/are rejected under 35 U.S.C. 103 as being unpatentable over RYU in view of Thiebaut, FORSSELL, GUPTA, Xi, and JP 2018537927 A.
Referring to claim(s) 20, Ryu and Thiebaut do not disclose wherein said first message is an EAP responsive identity request message, which is well-known in the art, which Forssell discloses,
[0121] In certain embodiments, a HetNet user/UE identity may correspond to a radius user name During WLAN hotspot authentication, the UE may identify itself to the AAA server in an EAP-Identity/Response message by providing a username@realm, for example, john.smith@mcc.mnc.3gpp.com. In this example, “John Smith” may be a username, and an MCC (mobile country code) and an MNC (mobile network code) may identify a country and a network operator, respectively. The UE may provide a used WLAN username@realm identity to RAN within a RRC message. The RAN and WLAN networks may exchange user/UE related messages by using the identity. [0140] In certain embodiments of the present invention, an authentication request from the UE will then be forwarded to the AAA server based on the used realm in the identity. The AAA may not know this PTID, but the AAA may explicitly inquire the proper EAP-SIM/AKA identity from the UE. The AAA may inquire the identity using an EAP-Identity Request message (such an inquiry is in accordance with the current standards when an anonymous identification is used). Such an inquiry allows the AAA to properly authenticate the user. The WLAN AP may continue to use an original PTID in Radius messages as an outer user identity in all AAA communication. In certain embodiments, the IMSI may possibly not be revealed to any party of the communication, and the IMSI may not be required by any party. The RAN and WLAN network may communicate using this PTID identity as UE identification.
Therefore, it would have been obvious to one of ordinary skill in the art at the time of the effective filing date of the claimed invention to modify the invention disclosed by Ryu to implement these limitations and also one of ordinary skill in the art would have been motivated to do so because it could provide utilizing identity request message, The identity would be provided by the device, which would allow the requesting entity to verify the identification, para 50, 51.
EAP emergency attach (response to the emergency attach request) is rejected in claim 1. Ryu, FORSSELL and Thiebaut do not disclose wherein said second message is an attach initiation message, which is well-known in the art, which Gupta discloses,
Figure 4 shows a UE 410 performing an authentication with a network/EAP server 450. Figure 4 has been simplified for illustrative purposes and does not show an EAP authenticator (WLAN access point). The EAP authenticator (not shown) acts as an intermediary for EAP message exchange between the UE (EAP peer) 410 and the EAP server (3GPP AAA Server) 450. As shown in Figure 4, an EAP Request message 412 and an EAP response message 414 that are communicated between the UE 410 and the EAP server 450 are configured to carry attach parameters comprising an APN parameter, an NSWO parameter and an HO (handover) parameter, second last para, page 7
Therefore, it would have been obvious to one of ordinary skill in the art at the time of the effective filing date of the claimed invention to modify the invention disclosed by Ryu to implement these limitations and also one of ordinary skill in the art would have been motivated to do so because it could provide utilizing message that would carry parameters to accomplish attach of the device. The communication of the messages between the EPA server and the EPA client would carry APN associated information for implementation, second last para, page 7. Ryu, FORSSELL, Gupta, and Thiebaut do not disclose an indication regarding an access point status for said UE, which is well-known in the art, which Xi discloses, para 113, 68. Therefore, it would have been obvious to one of ordinary skill in the art at the time of the effective filing date of the claimed invention to modify the invention disclosed by Ryu to implement these limitations and also one of ordinary skill in the art would have been motivated to do so because it could provide utilizing the information about the access point. The information of the EAP message would enable establish a connection with the user device, para 113, 68.
Ryu, Gupta, Xi and Thiebaut do not disclose connection parameters indicate support for one or more connection modes, which is well-known in the art, which JP 2018537927 A discloses,
The 6.3GPP AAA server sends an EAP request / AKA 'challenge, where the 3GPP AAA server sends a TWAN connection mode (eg, TSCM, SCM and MCM) supported by the network, which is unauthenticated, Indicates to the UE that the access is for a limited service . The result code AVP in the DEA message is set to DIAMETER_MULTI_ROUND_AUTH. The TWAN-S2a connectivity indicator is not set in the DEA flag AVP. The DEA message also contains an indication that this is access for limited services without authentication, fifth para, page 7
Therefore, it would have been obvious to one of ordinary skill in the art at the time of the effective filing date of the claimed invention to modify the invention disclosed by Ryu to implement these limitations and also one of ordinary skill in the art would have been motivated to do so because it could provide utilizing the connection mode. A single connection mode or a multi-connection mode would be specified by the parameter sent by the server. This would enable implementing a desired connection mode among the modes for further communication, fifth para, page 7.
Claim(s) 16, Is/are rejected under 35 U.S.C. 103 as being unpatentable over RYU in view of Thiebaut, VALLABHU and Sedlacek et al., 20160285627.
Referring to claim(s) 16, Li, Ryu, VALLABHU do not disclose, which is well-known in the art, which Sedlacek discloses, after performing said transmitting and receiving steps, exchanging key information with said server (for example, as per the specification, exchanging, EAP-AKA/ use of EAP-Master session key, para 126, 127, 135). Therefore, it would have been obvious to one of ordinary skill in the art at the time of the effective filing date of the claimed invention to modify the invention disclosed by Ryu to implement these limitations and also one of ordinary skill in the art would have been motivated to do so because it could provide utilizing well-known exchanging key information among a device and a server. The key would enable a session between the server and the device and would make the session secure using the well-known key, para 126, 127, 135.
Claim(s) 3, Is/are rejected under 35 U.S.C. 103 as being unpatentable over RYU in view of Thiebaut, GUPTA, WO 2017129089 A1, ZHU et al., and JP 2018537927 A.
Referring to claim(s) 3, EAP emergency attach (response to the emergency attach request) is rejected in claim 1. Ryu and Thiebaut do not disclose wherein said second message is an attach initiation message, which is well-known in the art, which Gupta discloses,
Figure 4 shows a UE 410 performing an authentication with a network/EAP server 450. Figure 4 has been simplified for illustrative purposes and does not show an EAP authenticator (WLAN access point). The EAP authenticator (not shown) acts as an intermediary for EAP message exchange between the UE (EAP peer) 410 and the EAP server (3GPP AAA Server) 450. As shown in Figure 4, an EAP Request message 412 and an EAP response message 414 that are communicated between the UE 410 and the EAP server 450 are configured to carry attach parameters comprising an APN parameter, an NSWO parameter and an HO (handover) parameter, second last para, page 7
Therefore, it would have been obvious to one of ordinary skill in the art at the time of the effective filing date of the claimed invention to modify the invention disclosed by Ryu to implement these limitations and also one of ordinary skill in the art would have been motivated to do so because it could provide utilizing message that would carry parameters to accomplish attach of the device. The communication of the messages between the EPA server and the EPA client would carry APN associated information for implementation, second last para, page 7. Ryu, Gupta, and Thiebaut do not disclose an indication regarding an access point status for said UE, which is well-known in the art, which Zhu discloses, para 113, 68. Therefore, it would have been obvious to one of ordinary skill in the art at the time of the effective filing date of the claimed invention to modify the invention disclosed by Ryu to implement these limitations and also one of ordinary skill in the art would have been motivated to do so because it could provide utilizing the information about the access point. The information of the EAP message would enable establish a connection with the user device, col., 4, lines 1-3.
Ryu, Gupta, Zhu and Thiebaut do not disclose connection parameters indicate support for one or more connection modes, which is well-known in the art, which JP 2018537927 A discloses,
The 6.3GPP AAA server sends an EAP request / AKA 'challenge, where the 3GPP AAA server sends a TWAN connection mode (eg, TSCM, SCM and MCM) supported by the network, which is unauthenticated, Indicates to the UE that the access is for a limited service . The result code AVP in the DEA message is set to DIAMETER_MULTI_ROUND_AUTH. The TWAN-S2a connectivity indicator is not set in the DEA flag AVP. The DEA message also contains an indication that this is access for limited services without authentication, fifth para, page 7
Therefore, it would have been obvious to one of ordinary skill in the art at the time of the effective filing date of the claimed invention to modify the invention disclosed by Ryu to implement these limitations and also one of ordinary skill in the art would have been motivated to do so because it could provide utilizing the connection mode. A single connection mode or a multi-connection mode would be specified by the parameter sent by the server. This would enable implementing a desired connection mode among the modes for further communication, fifth para, page 7.
Claim(s) 10, Is/are rejected under 35 U.S.C. 103 as being unpatentable over RYU in view of Thiebaut, GUPTA, Zhu, and JP 2018537927 A.
Referring to claim(s) 10, Zhu discloses wherein said indication regarding an access point status for said UE indicates that said UE is accessing a network (col., 4, lines 1-3) via a trusted Wireless LAN access point (Thiebaut, para 59, 52).
Claim(s) 16, Is/are rejected under 35 U.S.C. 103 as being unpatentable over RYU in view of Thiebaut, VALLABHU and ROELAND et al., 20160295405.
Referring to claim(s) 16, Li, Ryu, VALLABHU do not disclose, which is well-known in the art, which Roeland discloses, after performing said transmitting and receiving steps, exchanging key information with said server (for example, as per the specification, exchanging the key with the server, para 58-61). Therefore, it would have been obvious to one of ordinary skill in the art at the time of the effective filing date of the claimed invention to modify the invention disclosed by Ryu to implement these limitations and also one of ordinary skill in the art would have been motivated to do so because it could provide utilizing well-known exchanging key information among a device and a server. The key would enable a communication between the server and the device and would make the communication secure using the well-known key, para 58-61.
Claim(s) 2, Is/are rejected under 35 U.S.C. 103 as being unpatentable over RYU in view of Thiebaut and Liu et al., WO 2013104247 A1.
Referring to claim(s) 2, Ryu and Thiebaut do not disclose wherein said first message is an EAP responsive identity request message, which is well-known in the art, which Liu discloses, Steps 302-310: The TNAN acts as an EAP Authenticator and triggers an EAP authentication process to the UE. The UE carries the APN requested by the UE to the TNAN in the EAP-RES/Identity message. And the TNAN decides whether to allow the UE to carry the requested APN according to the requested APN and the local policy carried by the UE, specifically: if the TNAN supports the UE to carry the requested APN, the subsequent process is continued; otherwise, the subsequent operation is in the prior art. The process of the UE does not carry the requested APN is the same. The solution for the UE to obtain the IP address includes the following methods: Mode 1: The EAP authentication message triggers the TNAN to create a session, and the session allocates an IP address to the UE. Optionally, the TNAN carries the APN requested by the UE to the AAA in the EAP-RES/Identity message, and then the AAA carries the APN requested by the UE to the HSS in the Request Profile message, and the HSS determines not according to the received APN information. Send the default APN to AAA, third para, page 7. Therefore, it would have been obvious to one of ordinary skill in the art at the time of the effective filing date of the claimed invention to modify the invention disclosed by Ryu to implement these limitations and also one of ordinary skill in the art would have been motivated to do so because it could provide utilizing identity request message, The identity would be provided by the device, which would allow the requesting entity to verify the identification, third para, page 7.
Claim(s) 2, Is/are rejected under 35 U.S.C. 103 as being unpatentable over RYU in view of Thiebaut and Drevon et al., 2018/0317087.
Referring to claim(s) 2, Ryu and Thiebaut do not disclose wherein said first message is an EAP responsive identity request message, which is well-known in the art, which Drevon discloses, para 166, 133. Therefore, it would have been obvious to one of ordinary skill in the art at the time of the effective filing date of the claimed invention to modify the invention disclosed by Ryu to implement these limitations and also one of ordinary skill in the art would have been motivated to do so because it could provide utilizing identity request message, The identity would be provided by the device, which would allow the requesting entity to verify the identification, para 166, 133.
Claim(s) 16, Is/are rejected under 35 U.S.C. 103 as being unpatentable over RYU in view of Thiebaut, VALLABHU and Jung et al., 20160242033.
Referring to claim(s) 16, Li, Ryu, VALLABHU do not disclose, which is well-known in the art, which Jung discloses, after performing said transmitting and receiving steps, exchanging key information with said server (for example, as per the specification, exchanging the key with the server, para 133). Therefore, it would have been obvious to one of ordinary skill in the art at the time of the effective filing date of the claimed invention to modify the invention disclosed by Ryu to implement these limitations and also one of ordinary skill in the art would have been motivated to do so because it could provide utilizing well-known exchanging key information among a device and a server. The key would enable a communication between the server and the device and would make the communication secure using the well-known key, para 133.
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 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.
Claims 1, 19, 21 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Wang et al., , 20160295385 102(a)(1).
Referring to claims 1 and 19, Wang discloses UE configured to, a method of exchanging connection parameters using Extensible Authentication Protocol (EAP) messages, the method comprising: sending, to a server from a user equipment (UE), a first message indicating an emergency attach request (step 801 , figure 8, para 101-108); and the UE receiving a second message from the server in response to the first message, wherein said second message comprises one or more connection parameters (step 805, figure 8, para 101-108) and said sending and receiving is enabled without mutual authentication between the server and the UE (step 801, 805, figure 8, para 101-108), wherein said messages are EAP messages, para 82, said server and said UE are not mutually authenticated, (step 801, 805, figure 8, para 101-108).
Referring to claim 21, Wang discloses a user equipment (UE) for communicating with a server, comprising: a receiving module, configured to receive, at said UE from said server, one or more emergency attach identity message, emergency attach initiation message, and emergency attach notification message comprising one or more connection parameters (steps 801-809 , figure 8, para 101-108); and a transmitting module, configured to transmit, from said UE to said server, one or more of a responsive emergency attach identity message, a responsive emergency attach initiation message (steps 801-809 , figure 8, para 101-108), and a responsive emergency attach notification message comprising one or more connection parameters (steps 801-809 , figure 8, para 101-108), wherein said messages are EAP messages, para 82 and said server and said UE are not mutually authenticated (steps 801-809 , figure 8, para 101-108).
Claim(s) 11, 12, is/are rejected under 35 U.S.C. 103 as being unpatentable over RYU in view of Thiebaut and Drevon.
Referring to claim(s) 11, Ryu and Thiebaut do not disclose wherein said first message comprises an IMSI or IMEI value of said UE, which is well-known in the art, which Drevon discloses, para 166, 133.
Therefore, it would have been obvious to one of ordinary skill in the art at the time of the effective filing date of the claimed invention to modify the invention disclosed by Ryu to implement these limitations and also one of ordinary skill in the art would have been motivated to do so because it could provide utilizing IMSI/IMEI information associated with a device. The IMSI/IMEI information would be sent from the device, which would enable performing an emergency attach for the device, para 166, 133.
Referring to claim(s) 12, Drevon discloses, wherein said first message comprises an IMSI or said identity message indicates that said UE does not include a UICC (para 89, 40, 111).
Claim(s) 8, Is/are rejected under 35 U.S.C. 103 as being unpatentable over RYU in view of Thiebaut, VALLABHU, KR 101589574 B1 and Devron.
Referring to claim(s) 8, KR 101589574 B1 discloses PCO, para first, page 4. Li, Ryu, VALLABHU, KR 101589574 B1 do not disclose, which is well-known in the art, which Devron discloses, PDN TYPE, TWAG user plane MAC addresses, TWAG control plane MAC addresses (para 93-96), IPV4/IPV6 address (para 93-96). Therefore, it would have been obvious to one of ordinary skill in the art at the time of the effective filing date of the claimed invention to modify the invention disclosed by Ryu to implement these limitations and also one of ordinary skill in the art would have been motivated to do so because it could provide utilizing well-known connection parameter and a response. When the UE is attached to a network, connection parameters that can be used to establish connections would be specified and communicated across network. The parameters would enable configuring the connections, para 93-96.
Conclusion
Rejections of limitations under Thiebaut et al., 20180332457 and Drevon et al., 20180317087 of parent application are applicable in this application. Please above rejections for the limitations rejected under Thiebaut and Drevon.
Pertinent References:
Liu et al., US 20120094629 A1 [0164] The UE is in the IDLE state and moves from a B-category cell to an A-category cell in a TA that is in the same TAI list as the TA of the B-category cell. The UE initiates an Attach procedure in an A-category cell, and sends an Attach Request message through an HeNB to an MME, and sets Attach Type to "Emergency" in the Attach Request message to identify an emergency Attach. If no valid GUTI or packet temporary mobile subscriber identity (P-TMSI, Packet Temporary Mobile Subscriber Identity) is available, the Attach Request message may include the IMSI. If no IMSI is available, the Attach Request message may include the IMEI.
All claims are identical to or patentably indistinct from (office action dated 7/13/23, 18/150,297 parent application), or have unity of invention with claims in the application prior to the entry of the submission under 37 CFR 1.114 (that is, restriction (including a lack of unity of invention) would not be proper) and all claims could have been finally rejected on the grounds and art of record in the next Office action if they had been entered in the application prior to entry under 37 CFR 1.114. Accordingly, THIS ACTION IS MADE FINAL even though it is a first action after the filing of a request for continued examination and the submission under 37 CFR 1.114. See MPEP § 706.07(b). 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 HARESH PATEL whose telephone number is (571)272-3973. The examiner can normally be reached on M-F 9-5:30.
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, Jorge L. Ortiz-Criado, can be reached at (571) 272-7624. The fax phone number for the organization where this application or proceeding is assigned is (571) 273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/HARESH N PATEL/Primary Examiner, Art Unit 2496
Prosecution Insights