Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
This is a first office action in response to an application for letters patent filed on 21 November 2024. Claims 1-19 are presented for examination.
Information Disclosure Statement
The information disclosure statement (IDS) submitted on 11/21/2024 was filed before the mailing date of the first office action on the merits. The submission is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
the claimed invention lacks patentable utility. Claim 19, line 1, recites computer-readable medium. Paragraph 0064 of the specification is silent about what medium is and is not. Correction is requested by replacing medium with device or by inserting –non-transitory—before computer-readable medium.
Claim Rejections - 35 USC § 102
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)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
Claim(s) 1-19 are rejected under 35 U.S.C. 102(a)(2) as being anticipated by Adrian et al. hereinafter Adrian Pub Number 20230137082.
As per claim 11, Adrian teaches a method for securing a communication channel over a mobile communication network (see par 0033, wherein many wireless networks are mentioned such as 4G, %G etc), the method to be executed by a secure element (see par 0048, “…:UICC”, which is part of UE) according to claim 1, the method comprising the following steps to be executed in the following order: determining, directly after the session being initialized, whether a fresh bootstrapping operation is required (see fig 5, par 0026-0027, 0102-0103; pre-shared key (PSK) renegotiation in a generic bootstrapping architecture (GBA). In various embodiments, a user equipment (UE) and a network device, such as a Network Application Function (NAF) server, may communicate information that enables the NAF to indicate when PSK renegotiation is required for a bootstrapping procedure, such as one or more GBA methods, for example, mobile equipment (ME) based GBA (GBA_ME), GBA with Universal Integrated Circuit Card (UICC) based enhancements (GBA_U), Second Generation (2G) GBA, GBA Digest (a method using session information protocol (SIP) digest credentials for GB)), wherein the bootstrapping operation is configured to generate a shared key for establishing the secure communication channel to the mobile network entity (see par 0102-0103; The prefix “3GPP-bootstrapping” may be used in the PSK-identity to indicate that the UE accepts that AKA-based Ks_(ext)_NAF is used to establish the TLS session keys. The prefix “3GPP-bootstrapping-uicc” may be used in the PSK-identity to indicate that the UE accepts that Ks_int_ NAF is used to establish the TLS sessions keys. The prefix “3GPP-bootstrapping-digest” is used in the PSK-identity to indicate that the UE accepts that GBA_Digest-based Ks_NAF is used to establish the TLS sessions keys); and
opening the secure communication channel to the mobile network entity (see fig 5, box 518).
As per claim 12, Adrian inherently teaches the method of claim11, wherein the determining, whether the fresh bootstrapping operation is required, comprises: autonomously determining whether the fresh bootstrapping operation is required (see par 0048, The PSK identities in the ClientHello may include prefixes indicating the PSK-identity namespace (such as “3GPP-bootstrapping-uicc”, “3GPP-bootstrapping”, and/or “3GPP-bootstrapping-digest”), and the associated B-TID associated with that bootstrapping method. In various embodiments, for each of these included identifiers (e.g., the PSK-identity namespaces, such as “3GPP-bootstrapping-uicc”, “3GPP-bootstrapping”, and/or “3GPP-bootstrapping-digest”), an additional PSK-identity namespace may be included to enable the request for fresh session key(s)).
As per claim 13, Adrian teaches the method of claim 12, wherein the autonomously determining is based on the first session bootstrap parameter stored in the secure storage unit of the secure element (see fig 5, elements 502, 504; par 0048).
As per claim 14, Adrian teaches the method of claim 11, wherein the determining, whether the fresh bootstrapping operation is required, comprises: - receiving the indication comprising the second session bootstrap parameter from the mobile network entity during initialization of the session, and determining based on the second session bootstrap parameter, whether the fresh bootstrapping operation is required (see par 0048, The PSK identities in the ClientHello may include prefixes indicating the PSK-identity namespace (such as “3GPP-bootstrapping-uicc”, “3GPP-bootstrapping”, and/or “3GPP-bootstrapping-digest”), and the associated B-TID associated with that bootstrapping method. In various embodiments, for each of these included identifiers (e.g., the PSK-identity namespaces, such as “3GPP-bootstrapping-uicc”, “3GPP-bootstrapping”, and/or “3GPP-bootstrapping-digest”), an additional PSK-identity namespace may be included to enable the request for fresh session key(s)).
As per claim 15, The method of clam 11, wherein the determining, whether the fresh bootstrapping operation is required, comprises: autonomously determining whether the fresh bootstrapping operation is required, receiving the indication comprising the second session bootstrap parameter from the mobile network entity during initialization of the session, and determining based on the second session bootstrap parameter, whether the fresh bootstrapping operation is required (see par 0049, a new bootstrapping …).
As per claim 16, Adrian teaches the method of claim 15, wherein the autonomously determining is based on the first session bootstrap parameter stored in the secure storage unit of the secure element (see claim 15).
As per claim 17, Adrian teaches the method of any of claims 11, further comprising: setting the value of the first session bootstrap parameter to "not required" after completion of the fresh bootstrap operation (see par 0049, a network device, such as an NAF, may determine whether or not to have a UE perform a new bootstrapping procedure for a particular method. In response to the network device determining that the UE should perform a new bootstrapping to obtain a fresh session key for a particular GBA method, the network device may return the indication (e.g., namespace, index, position, etc.) of the renegotiation of the selected PSK-identity (or bootstrapping procedure) in the ServerHello message replying to the UE).
As per claim 18, Adrian teaches the method of claim 11, further comprising: sending a client-hello message, wherein the client-hello message comprises a prefix indicating a namespace of a chosen bootstrapping method and a bootstrapping transaction identifier (see par 0048, “The PSK identities in the ClientHello may include prefixes indicating the PSK-identity namespace (such as “3GPP-bootstrapping-uicc”, “3GPP-bootstrapping”, and/or “3GPP-bootstrapping-digest”), and the associated B-TID associated with that bootstrapping method. In various embodiments, for each of these included identifiers (e.g., the PSK-identity namespaces, such as “3GPP-bootstrapping-uicc”, “3GPP-bootstrapping”, and/or “3GPP-bootstrapping-digest”), an additional PSK-identity namespace may be included to enable the request for fresh session key(s”).
As per claim 19, Adrian teaches a computer-readable medium comprising instructions, which, when executed in a secure element, cause the secure control unit to carry out the method steps of claim 11 (see claim 11 rejection which is a method of this claim).
As per claim 1, It contains the same limitation as discussed in claim 11 rejected above.
As per claim 2, (see claim 12).
As per claim 3, Adrian teaches the secure element of claim 1, further comprising a secure storage unit, in which a first session bootstrap parameter is stored, wherein the secure control unit is configured to determine, based on the value of the first session bootstrap parameter, whether the fresh bootstrapping operation is required, wherein the value of the first bootstrap parameter represents one of "bootstrapping required" or "not required" (see fig 5, par 0049, determining whether or not to have a UE perform a new bootstrapping procedure …).
As per claim 4, Adrian teaches the secure element of claim1, wherein the secure control unit is configured to receive an indication comprising a second session bootstrap parameter of the mobile network entity during initialization of the session and to determine, based on the second bootstrap parameter, whether the fresh bootstrapping operation is required, wherein the value of the second bootstrap parameter represents one of "bootstrapping required" or "not required" (see par 0048, The PSK identities in the ClientHello may include prefixes indicating the PSK-identity namespace (such as “3GPP-bootstrapping-uicc”, “3GPP-bootstrapping”, and/or “3GPP-bootstrapping-digest”), and the associated B-TID associated with that bootstrapping method. In various embodiments, for each of these included identifiers (e.g., the PSK-identity namespaces, such as “3GPP-bootstrapping-uicc”, “3GPP-bootstrapping”, and/or “3GPP-bootstrapping-digest”), an additional PSK-identity namespace may be included to enable the request for fresh session key(s)).
As per claim 5, Adrian teaches the secure element of claim 4, wherein, when the indication comprises the second session bootstrap parameter, the secure control unit is configured to determine whether the fresh bootstrapping operation is required based on prioritizing the second session bootstrap parameter transmitted within the indication over the first session bootstrap parameter stored in the secure storage module (see par 0049, a new bootstrapping …).
As per claim 6, Adrian teaches the secure element of claim 5, wherein the secure control module is adapted to determine whether the fresh bootstrapping operation is required based on the second bootstrap parameter first, and, if the indication is not provided by the mobile network entity, to read out the value of the first bootstrap parameter (see claim 5).
As per claim 7, Adrian teaches the secure element of claim 1, wherein the secure control unit is further adapted to set the value of the first session bootstrap parameter to "not required" after completion of the fresh bootstrap operation (see par 0049, a network device, such as an NAF, may determine whether or not to have a UE perform a new bootstrapping procedure for a particular method. In response to the network device determining that the UE should perform a new bootstrapping to obtain a fresh session key for a particular GBA method, the network device may return the indication (e.g., namespace, index, position, etc.) of the renegotiation of the selected PSK-identity (or bootstrapping procedure) in the ServerHello message replying to the UE).
As per claim 8, (see claim 18).
As per claim 9, Adrian teaches a system for securely communicating over a mobile communication network, the system comprising: a terminal device comprising: a secure element according to claim 1; and a communication interface which is adapted to communicate via the mobile communication network, wherein the terminal device is configured to: receive a push request from a mobile network entity or transmit a pull request to the mobile network entity to initiate a session with the mobile network entity, forward the push request to or the pull request from the secure element, execute a bootstrapping operation, if determined to be required, and open the secure communication channel to the mobile network entity; and the mobile network entity which is configured to: transmit a push request to the terminal device or receive a pull request from the terminal device, participate in executing the bootstrapping operation, if determined to be required, and establish the secure communication channel to the communication interface of the terminal device (claim 11 contains most features of this claim; furthermore, fig 1A discloses UE that that allows push and pull request; in addition par 0026 discusses (SIP) session information protocol; see par 0103 as well).
As per claim 10, Adrian teaches the system of claim 9, wherein the terminal device is further adapted to send a client- hello based on the shared key, and wherein the mobile network entity is adapted to respond to the client hello using a server-hello based on the shared key (see fig 5, par 0026-0027, 0036, 0048; enable pre-shared key (PSK) renegotiation in a generic bootstrapping architecture (GBA). In various embodiments, a user equipment (UE) and a network device, such as a Network Application Function (NAF) server, may communicate information that enables the NAF to indicate when PSK renegotiation is required for a bootstrapping procedure,).
Any inquiry concerning this communication or earlier communications from the examiner should be directed to FRANTZ B JEAN whose telephone number is (571)272-3937. The examiner can normally be reached 8-5 M-F.
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, Glenton B. Burgess can be reached at 5712723949. 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.
/FRANTZ B JEAN/Primary Examiner, Art Unit 2454
Prosecution Insights