Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Detailed Action
Claims 1, 3-5, 8, 10-17, 19, and 20 have been amended
Claims 2, 9, and 18 have been cancelled
Claims 1, 3-8, 10-17, 19, and 20 are pending
Priority
This application claims priority under 35 U.S.C. § 119 to Korean Patent Application No. 10-2024-0027507, filed on Feb. 26, 2024, in the Korean Intellectual Property Office. Therefore, the effective filing date of this application is 02/26/2024.
Response to Arguments
Applicant’s arguments filed on 06/22/2026 have been fully considered.
With respect to the USC 112(f) claim interpretation for the recitation of the limitation “… security device configured to” in claims 1, 8, and 17. The interpretation has not been overcome. The claim has been amended to recite of a mode controller comprising memory. However, the functional language of a security device configured to is still being recited. Therefore, the interpretation for claims 1, 8, and 17 is maintained.
With respect to the USC 112(b) rejection for claims 2-5, 9-12, 18, and 19. Claims 2, 9, and 18 have been cancelled. However, claims 3, 10, and 19 still recite of the OTP value being changed. As seen in the rejection below a one-time programmable (OTP) value cannot be changed once it is programmed. It is unclear how an OTP value as recited in these claims can change in an increasing direction or decreasing direction. Therefore, claims 3-5, 10-12, and 19 are still being rejected under USC 112(b).
With respect to the USC 103 rejection Applicant has argued that ZHANG-JOHANSSON fails to teach “wherein the OTP value is based on one or more one-time changeable bits, wherein the mode controller is configured to access the OTP value from the OTP memory and set, based on the OTP value, a security mode”. Applicant has argued that the Type-Length-Value (TLV) of ZHANG is not a one-time programmable (OTP) value. Examiner respectfully disagrees. Applicant has cited para. 0041 and 0042 of ZHANG to show that bits of the TLV are changing. However, these paragraphs do not indicate such thing. Para. 0041 of ZHANG describes of an authentication mode selected when a terminal is used for the first time, and para. 0042 of ZHANG describes of selecting a different mode of authentication when a device is restarted. However, these paragraphs do not indicate of the TLV being changed or modified. ZHANG teaches ([ZHANG, para. 0042] “When the authentication modes respectively supported by the terminal and the authentication server include the previous authentication modes, the authentication server can select one of them as the authentication mode used in the process of authentication.”) ([ZHANG, para. 0048] “the authentication mode supported by the terminal and the authentication mode supported by both the terminal and the authentication server are represented with triples of Type-Length-Value, TLV. Furthermore, the mode is represented with Boolean type value of the content field in the TLV. Table 1 provides an example.”) ([ZHANG, para. 0049] “The length of the TLV is one or two bytes, where each bit can be preset to correspond to an authentication mode. If the bit is set to 1, it indicates that the authentication mode is supported. For example, if Bit#0 is set to 1, the EAP-TLS method is supported. “). As seen from these citations of ZHANG the TLV consists of bits being set and based on a corresponding bit position set to 1 it is indicated that that authentication referenced by that specific bit position is supported. Returning back to the description in para. 0041 and 0042 because the terminal and authentication server support EAP-TLS for a first time authentication and EAP-TTLS for user authentication on a restart the TLV value will be set to 1 for both Bit#0 and Bit#1. As seen further in Table 1 of ZHANG the example shows if Bit#0 is set to 1, the EAP-TLS method is supported and if Bit#1 is set to 1, the EAP-TTLS method is supported. The TLV is not being changed after a restart or in a change of operating status as indicated by the Applicant. The TLV indicates based on bit positions corresponding authentication modes that are supported. ZHANG teaches ([ZHANG, para. 0052] “ the TLV is added during the capacity negotiation process between the terminal, the base station and the authentication server before the authentication is performed, where the TLV carries the authentication mode supported by the terminal and the authentication mode supported by both the terminal and the server. In addition, a dynamic negotiation of authentication mode between the terminal and the authentication server is realized before the authentication process, so that the subsequent authentication can be performed smoothly.”). Nowhere in ZHANG does it teach that the TLV value is modified. Furthermore, for the TLV value to be changed first the terminals and authentication server of ZHANG will need to be modified to support different authentication modes, this is not possible or even described in ZHANG. Therefore, the TLV of ZHANG is analogous to the OTP value recited in the claims from which a security mode is set.
As for the newly amended limitations of “a mode controller comprising a one-time programmable (OTP) memory storing, a OTP value, … wherein the mode controller is configured to access the OTP value from the OTP memory and set, based on the OTP value, a security mode” Examiner is now relying on a new third reference BROKISH to better teach this limitation. BROKISH teaches ([BROKISH, para. 0011] “ a method for secure or less secure operation of a processor including storing an identification value and boot code. Depending on the identification value, the method executes a selected boot sequence from the boot code either for more secure operation or for less secure operation.”) ([BROKISH, para. 0032] “Processor integrated circuit 122 includes at least one processor (or central processing unit CPU) block 130 coupled to an internal (on-chip read-only memory) ROM 132, an internal (on-chip random access memory) RAM 134, and an internal (on-chip) flash memory 136. A security logic circuit 138 is coupled to secure-or-general-purpose-identification value (Security/GPI) bits 140 of a non-volatile one-time alterable Production ID register or array of electronic fuses (E-Fuses). Such E-Fuses are an example of an identification code storage holding an identification value. These E-Fuses are programmed in different units of the handset 110, 110′ to thereby provide a security identification store having non-volatile bits representing whether the wireless handset (or other system block) is a less secure (“GP” herein) type or more high-security type (“HS” herein).”) ([BROKISH, para. 0035] “ Processor 130 is coupled to the on-chip boot ROM 132, to the power-on reset circuit 142 and to the security identification bits 140 to selectively execute boot code depending on the non-volatile information of the security identification bits 140. Processor 130 is responsive to a security identification value represented by the bits 140 to execute a selected boot from boot storage either for more-secure (HS) operation or for less-secure operation of the processor 130. “) As seen from these citations BROKISH teaches of E-Fuses storing identification value that indicates if more-secure or less-secure operations should be executed. Therefore, the combination of ZHANG-JOHANSSON-BROKISH teaches all limitations of claim 1. Similar arguments apply for parallel independent claims 8 and 17.
Additional arguments are moot in view of new grounds of rejection necessitated by the claim amendments.
Claim Interpretation
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 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.
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 is:
“… security device configured to” in claims 1, 8, and 17
Because this claim limitation(s) is being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, it is being interpreted to cover the corresponding structure described in the specification as performing the claimed function, and equivalents thereof.
See specification para. [0027, 0058] for hardware support
See specification para. [0042-0047] for functional support
If applicant does not intend to have this 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 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 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.
Claims 3-5, 10-12, 17, 19, and 20 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim 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.
Claims 3, 10, and 19 recite the limitation “OTP value includes … one or more bits is changeable” and “the OTP value being changed”. A one-time programmable (OTP) value cannot be changed once it is programmed. It is unclear how an OTP value as recited in these claims can change in an increasing direction or decreasing direction. For the purpose of examination examiner is interpreting the change as changing to a different OTP value with corresponding bits that consist of increasing (1) and decreasing (0) values. As seen in Figure 3 which recites of four OTP values with corresponding bits changing. Appropriate correction is required.
Claims 4, 5, 11, and 12 depend on claims 3 and 10. Therefore, they also inherit the rejection.
Claim 17 recites the limitation "the plurality of IPs ". There is insufficient antecedent basis for this limitation in the claim. For the purpose of examination Examiner is interpreting this limitation as “the plurality of IP devices”. Appropriate correction is required.
Claims 19 and 20 depend on claim 17. Therefore, these claims also inherit the rejection.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1, 3, 4, 8, 10, 11, 15, and 16 are rejected under 35 U.S.C. 103 as being unpatentable over ZHANG (US-20100146262-A1) in view of JOHANSSON (US-10050787-B1), and further in view of BROKISH (US-20230084049-A1) hereinafter ZHANG-JOHANSSON-BROKISH.
Regarding claim 1, ZHANG teaches “A security device configured to control access authority of a user device, the security device comprising: a mode controller comprising … a OTP value, wherein the OTP value is based on one or more one-time changeable bits, … and set, based on the OTP value, a security mode, wherein the security mode indicates a method of authenticating the access authority of the user device; ([ZHANG, para. 0006] “The embodiments of the present disclosure provide a method for negotiating authentication mode. By using the method, an authentication mode supported by both a terminal and a network-side device is determined through a dynamic negotiation between the terminal and the network-side device before the authentication”) ([ZHANG, para. 0030] “the authentication server determines an authentication mode supported by both the authentication server and the terminal, where the authentication mode is determined according to an authentication mode supported by the authentication server and the authentication mode supported by the terminal in the first negotiation request, and sends the authentication mode supported by both the authentication server and the terminal to the terminal.”) ([ZHANG, para. 0048, table 1] “the authentication mode supported by the terminal and the authentication mode supported by both the terminal and the authentication server are represented with triples of Type-Length-Value, TLV. Furthermore, the mode is represented with Boolean type value of the content field in the TLV. Table 1 provides an example.”) ([ZHANG, para. 0049, table 1] “The length of the TLV is one or two bytes, where each bit can be preset to correspond to an authentication mode. If the bit is set to 1, it indicates that the authentication mode is supported. For example, if Bit#0 is set to 1, the EAP-TLS method is supported. During capacity negotiation, the MS carries the TLV in the BasicCapacities request message and reports the BasicCapacities request message to the BS, and then the BS sends the TLV to the authentication server that may be set in the GW, through a terminal state change request. The GW may select a certain authentication mode supported by both the GW and the MS and sends the selected authentication mode to the BS through terminal state change response message; and the BS sends the authentication mode to the MS through BasicCapacities response message.”) an authentication controller configured to determine, based on the security mode, whether to allow access of the user device; and ([ZHANG, para. 0074] “Further, the deciding unit comprises a judging unit and a determining unit.”) ([ZHANG, para. 0075] “The judging unit is adapted to judge whether the terminal passes a user authentication and a device authentication.”) ([ZHANG, para. 0081] “For example, if the authentication mode EAP-TLS corresponds to the device authentication, and this authentication mode is included both in the authentication mode supported by the terminal and in the authentication mode supported by the authentication server, the authentication server may select EAP-TLS as the negotiation result, for the subsequent process of the authentication.”)
However, ZHANG does not teach “a mode controller comprising a one-time programmable (OTP) memory storing, a OTP value, … wherein the mode controller is configured to access the OTP value from the OTP memory and set, based on the OTP value, a security mode … an access controller configured to activate or deactivate the access of the user device based on a result of the determination of the authentication controller”
In analogous teaching JOHANSSON teaches “access controller configured to activate or deactivate the access of the user device based on a result of the determination of the authentication controller.” ([JOHANSSON, col. 18 Lines 15-22] “The generated authentication response may then be provided from the identity provider 606 to the service provider 604. If the authentication response from the identity provider 606 indicates that authentication was successful, the service provider 604 may allow the user device 602 to access services (e.g., website functionality) for which authentication was required.”)
Thus, given the teaching of JOHANSSON, it would have been obvious to one of ordinary skill in the art before the effective filling date of the claimed invention to combine the teaching of granting access by JOHANSSON into the teaching of a security device configured to control access authority of a user device by ZHANG. One of ordinary skill in the art would have been motivated to do so because JOHANSSON recognizes the need to enhance data security ([JOHANSSON, col. 1 Lines 26-31] “To enhance data security, numerous techniques have been developed. For example, the use of username and password combinations has become ubiquitous in various access control contexts. Additional techniques are also often used in addition to or instead of usernames and passwords. A common issue encountered with conventional authentication techniques is the tradeoff between security and usability.”) ([JOHANSSON, col. 2 Lines 64-66] “Techniques described and suggested herein allow for increased data security while achieving a better user experience.”).
However, ZHANG-JOHANSSON does not teach “a mode controller comprising a one-time programmable (OTP) memory storing, a OTP value, … wherein the mode controller is configured to access the OTP value from the OTP memory and set, based on the OTP value, a security mode”
In analogous teaching BROKISH teaches “a mode controller comprising a one-time programmable (OTP) memory storing, a OTP value, … wherein the mode controller is configured to access the OTP value from the OTP memory and set, based on the OTP value, a security mode” ([BROKISH, para. 0011] “ a method for secure or less secure operation of a processor including storing an identification value and boot code. Depending on the identification value, the method executes a selected boot sequence from the boot code either for more secure operation or for less secure operation.”) ([BROKISH, para. 0032, Fig. 1] “ Processor integrated circuit 122 includes at least one processor (or central processing unit CPU) block 130 coupled to an internal (on-chip read-only memory) ROM 132, an internal (on-chip random access memory) RAM 134, and an internal (on-chip) flash memory 136. A security logic circuit 138 is coupled to secure-or-general-purpose-identification value (Security/GPI) bits 140 of a non-volatile one-time alterable Production ID register or array of electronic fuses (E-Fuses). Such E-Fuses are an example of an identification code storage holding an identification value. These E-Fuses are programmed in different units of the handset 110, 110′ to thereby provide a security identification store having non-volatile bits representing whether the wireless handset (or other system block) is a less secure (“GP” herein) type or more high-security type (“HS” herein).”) ([BROKISH, para. 0035] “ Processor 130 is coupled to the on-chip boot ROM 132, to the power-on reset circuit 142 and to the security identification bits 140 to selectively execute boot code depending on the non-volatile information of the security identification bits 140. Processor 130 is responsive to a security identification value represented by the bits 140 to execute a selected boot from boot storage either for more-secure (HS) operation or for less-secure operation of the processor 130. “).
Thus, given the teaching of BROKISH, it would have been obvious to one of ordinary skill in the art before the effective filling date of the claimed invention to combine the teaching of OTP memory by BROKISH into the teaching of a security device configured to control access authority of a user device by ZHANG-JOHANSSON. One of ordinary skill in the art would have been motivated to do so because BROKISH recognizes the need to improve security ([BROKISH, para. 0005] “Security techniques are used to improve the security of retail and other business commercial transactions in electronic commerce and to improve the security of communications wherever personal and/or commercial privacy is desirable.”) ([BROKISH, para. 0029] “In FIG. 1 an improved communications system 100 has system blocks with selectively-determinable security level. “) ([BROKISH, para. 0216] “the provision of the HS/GP Production ID [30:31] bits enabling the other improvements added and described in this detailed description, remarkably and advantageously does establish suitability for distribution as selectively-determined higher-security/lower-security products to users.”)
Regarding claim 3, ZHANG-JOHANSSON-BROKISH teach all limitations of claim 1. ZHANG further teaches “wherein the mode controller is configured to change the security mode based on the OTP value being changed. ([ZHANG, para. 0107] “During the negotiation, if a security tunnel is not required in the process of the EAP authentication, the length of the Type-Data field is one byte. In this case, the way in which the one byte represents authentication mode can be seen from the definition of the Value field in Table 1, i.e., each bit represents an authentication method, and when a certain authentication mode is used, the bit representing the authentication mode is set to 1. When a certain authentication mode is not used, the bit representing the authentication mode is set to 0. For example, if bit 0 represents EAP-TLS, when the authentication mode for both the terminal and the authentication server is EAP-TLS, bit 0 is set to 1.”)
Regarding claim 4, ZHANG-JOHANSSON-BROKISH teach all limitations of claim 3. ZHANG further teaches “wherein the OTP value is based on n−1 bits, n being a natural number greater than or equal to 2, and wherein the mode controller is configured to set the security mode to one of first to nth security modes based on a number of bits with a first logic value among the n−1 bits of the OTP value. ([ZHANG, para. 0049] “The length of the TLV is one or two bytes, where each bit can be preset to correspond to an authentication mode. If the bit is set to 1, it indicates that the authentication mode is supported. For example, if Bit#0 is set to 1, the EAP-TLS method is supported.”) ([ZHANG, para. 0107] “the length of the Type-Data field is one byte. In this case, the way in which the one byte represents authentication mode can be seen from the definition of the Value field in Table 1, i.e., each bit represents an authentication method, and when a certain authentication mode is used, the bit representing the authentication mode is set to 1. When a certain authentication mode is not used, the bit representing the authentication mode is set to 0. For example, if bit 0 represents EAP-TLS, when the authentication mode for both the terminal and the authentication server is EAP-TLS, bit 0 is set to 1.”) [Examiner’s note: ZHANG teaches of OTP value consisting of n-1 bits. The length of the TLV value is one or two bytes. There are 8 bits in a byte. Each bit represents an authentication method.]
Regarding claim 8, this claim recites of a security device configured to control access authority of a user device similar to the security device of claim 1. Therefore, claim 8 is rejected in a similar manner. JOHANSSON further teaches of “control access authority of a user device to a plurality of intellectual property (IP) devices … a security mode of the user device for each IP of the plurality of IP devices … each IP device of the plurality of IP devices …” ([JOHANSSON, col. 7 Lines 21-39] “in some embodiments, authentication objects associated with one service provider may be usable with other service providers. … an authentication object manager may be configured with programming logic to detect what authentication objects are usable with a particular service provider, select those authentication objects from a set of authentication objects that includes one or more authentication objects unusable with the service provider, and provide representations of the selected authentication objects (excluding the unusable authentication objects) to make user identification of a suitable authentication object easier.”) ([JOHANSSON, col. 17 Lines 30-56] “users are described as providing authentication objects to service providers for verification thereby. … The identity provider 606 may be a computer system comprising a collection of computing devices collectively configured to manage authentication for a set of service providers including the service provider 604. The identity provider 606 may, for example, be an entity that operates its own services such as social networking services, an electronic commerce website, its own other type of website and/or other services.”) ([JOHANSSON, col. 17 Lines 46-48] “The service provider 604 may, for instance, provide a website or a backend system supporting a mobile or other application executing on the user device.”) ([JOHANSSON, col. 18 Lines 15-22] “identity provider 606 indicates that authentication was successful, the service provider 604 may allow the user device 602 to access services (e.g., website functionality) for which authentication was required.”)
[Examiner’s note: Examiner is interpreting service providers as plurality of intellectual properties (IPs).]
The same motivation to modify ZHANG with JOHANSSON as in the rejection of claim 1 applies.
Regarding claim 10, ZHANG-JOHANSSON-BROKISH teach all limitations of claim 8. JOHANSSON further teaches “wherein a number of the plurality of OTP values equals to a number of the plurality of IP devices, and wherein based on an mth OTP value being changed, the mode controller is configured to change the security mode for an mth IP device corresponding to the mth OTP value, m being a natural number.” ([JOHANSSON, col. 21 Lines 4-18] “the provisioning of an authentication object causes another system to perform one or more reconfiguration actions to be taken by another system. For instance, when an authentication object is provisioned using an authentication object manager, one or more communications (e.g., notifications), which may be cryptographically authenticated, may be transmitted to a service provider system to cause the service provider system to allow authentication objects generated in accordance with the various techniques described herein to be used for authentication. The other system may, for instance, update a database of authentication information such that, when a valid authentication object is used for authentication, the authentication succeeds whereas the authentication would not have succeeded absent the one or more communications.”) ([JOHANSSON, col. 26 Lines 17-23] “Once the authentication object has been generated 1008, the authentication object may be submitted 1010 to a service provider, such as described above. In this manner, the service provider may verify, or otherwise cause to be verified, the authentication object in order to determine whether to provide access for which an authentication is required.”).
The same motivation to modify ZHANG with JOHANSSON as in the rejection of claim 1 applies.
Regarding claim 11, ZHANG-JOHANSSON-BROKISH teach all limitations of claim 10. This claim recites of features similar to that of claim 4. Therefore, claim 11 is rejected in a similar manner as in the rejection of claim 4. Furthermore, JOHANSSON teaches of “IP devices” as can be seen in the rejection of claim 8. The same rejection and motivation apply.
Regarding claim 15, ZHANG-JOHANSSON-BROKISH teach all limitations of claim 8. JOHANSSON further teaches “wherein the authentication controller is configured to sequentially determine whether to allow the access of the user device to each IP device of the plurality of IP devices based on the security mode of each IP device of the plurality of IP devices.” ([JOHANSSON, col. 17 Lines 49-52] “The identity provider 606 may be a computer system comprising a collection of computing devices collectively configured to manage authentication for a set of service providers including the service provider 604.”) ([JOHANSSON, col. 18 Lines 2-8] “The identity provider 606 may process the authentication object 608, such as by cryptographically verifying the authentication object 608 and determining whether credentials and/or other information provided in the authentication object 608 are valid or otherwise satisfy one or more conditions for authentication”) ([JOHANSSON, col. 18 Lines 15-22] “The generated authentication response may then be provided from the identity provider 606 to the service provider 604. If the authentication response from the identity provider 606 indicates that authentication was successful, the service provider 604 may allow the user device 602 to access services (e.g., website functionality) for which authentication was required.”)
The same motivation to modify ZHANG with JOHANSSON as in the rejection of claim 1 applies.
Regarding claim 16, ZHANG-JOHANSSON-BROKISH teach all limitations of claim 8. JOHANSSON further teaches “wherein the access controller is configured to independently activate or deactivate the access of the user device to each IP device of the plurality of IP devices.” ([JOHANSSON, col. 18 Lines 15-22] “The generated authentication response may then be provided from the identity provider 606 to the service provider 604. If the authentication response from the identity provider 606 indicates that authentication was successful, the service provider 604 may allow the user device 602 to access services (e.g., website functionality) for which authentication was required.”)
The same motivation to modify ZHANG with JOHANSSON as in the rejection of claim 1 applies.
Claims 5 and 12 are rejected under 35 U.S.C. 103 as being unpatentable over ZHANG-JOHANSSON-BROKISH in view of KIM (US-20120159139-A1).
Regarding claims 5 and 12, ZHANG-JOHANSSON-BROKISH teach all limitations of claims 4 and 11. ZHANG further teaches “wherein the number of bits with the first logic value among the n−1 bits is k, k being a natural number of 0 to n−1, wherein the mode controller is configured to set the security mode to a (k+1)th security mode, and ([ZHANG, para. 0049] “The length of the TLV is one or two bytes, where each bit can be preset to correspond to an authentication mode. If the bit is set to 1, it indicates that the authentication mode is supported. For example, if Bit#0 is set to 1, the EAP-TLS method is supported.”) ([ZHANG, para. 0107, table 1] “the length of the Type-Data field is one byte. In this case, the way in which the one byte represents authentication mode can be seen from the definition of the Value field in Table 1, i.e., each bit represents an authentication method, and when a certain authentication mode is used, the bit representing the authentication mode is set to 1. When a certain authentication mode is not used, the bit representing the authentication mode is set to 0. For example, if bit 0 represents EAP-TLS, when the authentication mode for both the terminal and the authentication server is EAP-TLS, bit 0 is set to 1.”)
However, ZHANG-JOHANSSON-BROKISH does not teach “wherein an ith security mode has higher security strength than a jth security mode, i being a natural number of 2 to n, j being a natural number of 1 to n−1, and j being less than i.”
In analogous teaching KIM teaches “wherein an ith security mode has higher security strength than a jth security mode, i being a natural number of 2 to n, j being a natural number of 1 to n−1, and j being less than i. ([KIM, para. 0269] “For instance, if the conditional access is set on the second mode or the security level higher than that of the first mode is set on the second mode, the controller 180 can determine that the authentication procedure is necessary to enter the second mode.”) ([KIM, para. 0348] “Moreover, if an authentication procedure for entering a mode, to which a currently implemented mode will be switched, is requested in FIGS. 19A to 25B (e.g., if a conditional access is set on a mode to which a currently implemented mode will be switched, or if a security level higher than that of a currently implemented mode is set on a mode to which a currently implemented mode will be switched), the mobile terminal 100 receives an input of a user authentication information from a user.”)
Thus, given the teaching of KIM, it would have been obvious to one of ordinary skill in the art before the effective filling date of the claimed invention to combine the teaching of an ith security mode having higher security strength than a jth security mode by KIM into the teaching of a security device configured to control access authority of a user device by ZHANG-JOHANSSON-BROKISH. One of ordinary skill in the art would have been motivated to do so because KIM recognizes the need for a multi-mode user terminal ([KIM, para. 0008] “it is necessary to implement the mobile terminal suitable for both of the personal need and the business need. Moreover, the demand for using the mobile terminal for the purpose of the personal need or the business need separately keeps rising.”) ([KIM, para. 0010] “Accordingly, the present invention is directed to a mobile terminal and method of controlling a mode switching therein that substantially obviate one or more problems due to limitations and disadvantages of the related art.”)
Claims 6, 7, 13, 14 are rejected under 35 U.S.C. 103 as being unpatentable over ZHANG-JOHANSSON-BROKISH in view of BATEMAN (US-20140047143-A1), hereinafter ZHANG-JOHANSSON-BROKISH-BATEMAN.
Regarding claim 6, ZHANG-JOHANSSON-BROKISH teach all limitations of claim 1. ZHANG further teaches “wherein the mode controller is configured to set the security mode to one of first to fourth security modes based on the OTP value, ([ZHANG, para. 0049] “The length of the TLV is one or two bytes, where each bit can be preset to correspond to an authentication mode. If the bit is set to 1, it indicates that the authentication mode is supported. For example, if Bit#0 is set to 1, the EAP-TLS method is supported. During capacity negotiation, the MS carries the TLV in the BasicCapacities request message”) … wherein the second security mode is a mode of authenticating the access authority of the user device by using a password, ([ZHANG, para. 0079] “When the terminal is restarted, the terminal and the authentication server adopt user authentication because the terminal has user account information such as a user name and password. The user authentication is more secure than the device authentication adopted during the initial usage of the terminal.”).
JOHANSSON further teaches “… wherein the third security mode is a mode of authenticating the access authority of the user device by using a digital signature, and ([JOHANSSON, col. 27 Lines 1-12] “Upon collection 1104 of the authentication information, a cryptographic key may be used 1106 to digitally sign the authentication information. The key may, for example, be a symmetric key shared as a secret with a system that is to verify the authentication object, or may be a private key of a public/private key pair. Upon signing 1106 the authentication information, an authentication object may be generated 1108 from the sign authentication information, such as described above. The authentication object may comprise, for example, a certificate indicating a public key, usable to verify a digital signature of the authentication information and verifiable by an appropriate certificate authority.”) wherein the fourth security mode is a mode of authenticating the access authority of the user device by using the digital signature and a random value. ([JOHANSSON, col. 27 Lines 1-12] “Upon collection 1104 of the authentication information, a cryptographic key may be used 1106 to digitally sign the authentication information. The key may, for example, be a symmetric key shared as a secret with a system that is to verify the authentication object, or may be a private key of a public/private key pair. Upon signing 1106 the authentication information, an authentication object may be generated 1108 from the sign authentication information, such as described above. The authentication object may comprise, for example, a certificate indicating a public key, usable to verify a digital signature of the authentication information and verifiable by an appropriate certificate authority.”) [Examiner’s note: Examiner is interpreting cryptographic key a private/public key as a random value.].
The same motivation to modify ZHANG with JOHANSSON as in the rejection of claim 1 applies.
However, ZHANG-JOHANSSON-BROKISH does not teach “… wherein the first security mode is a mode of allowing the access of the user device without authentication …”
In analogous teaching BATEMAN teaches “… wherein the first security mode is a mode of allowing the access of the user device without authentication, …” ([BATEMAN, para. 0079] “Security flag 508 may indicate whether or not a security mode is required for the connection.”) ([BATEMAN, para. 0085] “FIGS. 6, 7, and 8 show illustrative processes for supporting the facilitated device connection or device pairing of the present invention. FIG. 6 shows an illustrative process 600 for automatically connecting to an AP or device using a machine-readable feature according to one embodiment of the present invention. At step 602, the machine-readable feature is acquired by a device.”) ([BATEMAN, para. 0087] “At step 605, a determination is made whether a PIN (or other access code) is required for the connection. For example, for the Bluetooth protocol, three security modes are defined in the Bluetooth Generic Access Profile (GAP). Security mode 1 is a non-secure mode in which a Bluetooth device does not initiate any security procedures. In security mode 1, both authentication and encryption may be bypassed. … An “untrusted” device doesn't have fixed relationships and its access to services is limited. For services, three security levels are defined: services that require authorization and authentication, services that require authentication only, and services that are open to all devices.”)
Thus, given the teaching of BATEMAN, it would have been obvious to one of ordinary skill in the art before the effective filling date of the claimed invention to combine the teaching of a first security mode is a mode of allowing the access of the user device without authentication by BATEMAN into the teaching of a security device configured to control access authority of a user device by ZHANG-JOHANSSON-BROKISH. One of ordinary skill in the art would have been motivated to do so because BATEMAN recognizes the need to pair devices and the benefits of Bluetooth ([BATEMAN, para. 0003] “cameras lack the ability to intelligently interact with online video services and local computers and to optimally use multiple video streams sent to different network destinations for different network purposes.”) ([BATEMAN, para. 0002] “Embodiments of the present invention generally relate to the management and operation of network cameras and the connection or pairing of wireless devices.”) ([BATEMAN, para. 0064] “Bluetooth includes several security features. Bluetooth implements confidentiality, authentication, and key derivation using custom algorithms based on the SAFER+ block cipher. Bluetooth key generation is generally based on a Bluetooth PIN, which must be input into both devices.”)
Regarding claim 7, ZHANG-JOHANSSON-BROKISH-BATEMAN teach all limitations of claim 6. JOHANSSON further teaches “wherein the authentication controller is configured to based on the security mode being the second security mode, determine whether to allow the access of the user device based on the password, ([JOHANSSON, col. 17 Lines 49-52] “The identity provider 606 may be a computer system comprising a collection of computing devices collectively configured to manage authentication for a set of service providers including the service provider 604.”) ([JOHANSSON, col. 6 Lines 48-55] “An authentication object, in an embodiment, is a collection of information sufficient and/or necessary for access to one or more service provider systems. The information for example may comprise credentials usable for access to a service provider system. In one example, an authentication object encodes a username and a password where the username and password are sufficient for access to the service provider system. ”) ([JOHANSSON, col. 29 Lines 33-38] “The techniques by which authentication objects are usable may vary in accordance with the devices on which an authentication object manager operates. FIG. 14, for example, shows an illustrative example of an embodiment enabling use of authentication objects on a mobile device 1400.”) based on the security mode being the third security mode, determine whether to allow the access of the user device based on the digital signature, and ([JOHANSSON, col. 27 Lines 13-20] “The authentication object may then be submitted 1110 to a service provider to enable the service provider to verify the digital signature of the authentication information, perform any other required analysis of the authentication object and authentication information and make a determination whether to provide access, based in part, on whether the service provider determines that the authentication object is valid for the access requested.”) based on the security mode being the fourth security mode, determine whether to allow the access of the user device based on the digital signature and the random value. ([JOHANSSON, col. 27 Lines 13-20] “The authentication object may then be submitted 1110 to a service provider to enable the service provider to verify the digital signature of the authentication information, perform any other required analysis of the authentication object and authentication information and make a determination whether to provide access, based in part, on whether the service provider determines that the authentication object is valid for the access requested.”) ([JOHANSSON, col. 27 Lines 1-12] “The authentication object may comprise, for example, a certificate indicating a public key, usable to verify a digital signature of the authentication information and verifiable by an appropriate certificate authority.”)
The same motivation to modify ZHANG with JOHANSSON as in the rejection of claim 1 applies.
Regarding claim 13, ZHANG-JOHANSSON-BROKISH teach all limitations of claim 8. This claim recites of features similar to that of claim 6. Therefore, claim 13 is rejected in a similar manner as in the rejection of claim 6. Furthermore, JOHANSSON teaches of “plurality of IP devices” as seen in claim 8. The same rejection and motivation apply.
Regarding claim 14, ZHANG-JOHANSSON-BROKISH teach all limitations of claim 13. This claim recites of features similar to that of claim 7. Therefore, claim 14 is rejected in a similar manner as in the rejection of claim 7. Furthermore, JOHANSSON teaches of “plurality of IP devices” as seen in claim 8. The same rejection and motivation apply.
Claims 17 and 19 are rejected under 35 U.S.C. 103 as being unpatentable over ZHANG-JOHANSSON-BROKISH in view of DAHLSTROM (US-20190335001-A1), hereinafter ZHANG-JOHANSSON-BROKISH-DAHLSTROM.
Regarding claim 17, this claim recites of a system-on-chip (SoC) comprising: a plurality of intellectual property (IP) devices; and a security device configured to perform the features of claims 1 and 8. Therefore, claim 17 is rejected in a similar manner as in the rejection of claims 1 and 8. Furthermore, JOHANSSON teaches of “a system-on-chip (SoC) comprising: a plurality of intellectual property (IP) devices” ([JOHANSSON, col. Lines ] “The service provider 604 may, for instance, provide a website or a backend system supporting a mobile or other application executing on the user device.”) ([JOHANSSON, col. Lines] “utilize information from a trusted platform module 232 of the computing device on which the browser application 202 executes.”) [Examiner’s note: Examiner is interpreting service provider applications executing on a user device as intellectual property (IP) devices being comprised in a system-on-chip (SoC) (user device).].
The same motivation to modify ZHANG with JOHANSSON as in the rejection of claim 1 applies.
However, ZHANG-JOHANSSON-BROKISH does not teach “system-on-chip (SoC) comprising … a security device”.
In analogous teaching DAHLSTROM teaches “system-on-chip (SoC) comprising … a security device” ([DAHLSTROM, abstract] “System-on-chip data security appliance (“SoC-DSA”) and methods of operating the same. In one embodiment, the SoC-DSA includes data security mechanisms enclosed within a protected boundary of a single chip. In some embodiments, isolation and access control features are hidden within an on-chip field-programmable gate array (“FPGA”). The isolation and access control features can be implemented such that they are not visible to or alterable by software executing on the processing cores of the SoC-DSA, which provides for continued data security”) ([DAHLSTROM, para. 0014] “A high assurance guard (“HAG”) is a computer system component that provides an interface between a sensitive “high-side” network and a less-sensitive “low-side” network, such as the Internet.”) ([DAHLSTROM, para. 0019] “A HAG can be implemented using a system-on-chip data security appliance (“SoC-DSA”) to address this and other challenges.”) ([DAHLSTROM, para. 0052] “The SoC-DSA provides data security by guaranteeing isolation and control of data security mechanisms in a manner that prevents observation and tampering from the processing cores. This functionality is facilitated by implementing isolation and control within the FPGA logic.”)
Thus, given the teaching of DAHLSTROM, it would have been obvious to one of ordinary skill in the art before the effective filling date of the claimed invention to combine the teaching of system on chip comprising a security device by DAHLSTROM into the teaching of a security device configured to control access authority of a user device by ZHANG-JOHANSSON-BROKISH. One of ordinary skill in the art would have been motivated to do so because DAHLSTROM recognizes the need to improve security of data ([DAHLSTROM, para. 0038] “Accordingly, new systems that enable data producers to efficiently secure data and enforce authorized data use are needed. These systems must provide mechanisms for expressing data usage policies and for associating data use polices with secured data.”) ([DAHLSTROM, para. 0052] “The SoC-DSA provides data security by guaranteeing isolation and control of data security mechanisms in a manner that prevents observation and tampering from the processing cores.”)
Regarding claim 19, ZHANG-JOHANSSON-DAHLSTROM teach all limitations of claim 17. Furthermore, this claim recites of features similar to that of claim 3. Therefore, claim 19 is rejected in a similar manner as in the rejection of claim 3.
Claim 20 is rejected under 35 U.S.C. 103 as being unpatentable over ZHANG-JOHANSSON-BROKISH-DAHLSTROM in view of BATEMAN (US-20140047143-A1).
Regarding claim 20, ZHANG-JOHANSSON-BROKISH-DAHLSTROM teach all limitations of claim 17. This claim recites of features similar to that of claim 6. Therefore, claim 20 is rejected in a similar manner as in the rejection of claim 6. Furthermore, JOHANSSON teaches of “plurality of IP devices” as seen in claim 8. The same rejection and motivation apply.
Pertinent Art
The prior art made of record and not relied upon is considered pertinent to applicant’s disclosure.
POWELL (US-20220150239-A1): This prior art teaches of a method of device authentication comprises receiving a password into an application of a user device; transmitting verification information of the password from the application to an authentication device; verifying, by the authentication device, validity of the password using the verification information; granting, by the authentication device, access by the user device to a secure resource when the password is valid; sending no indication of an invalid password to the user device when the authentication device determines the password is invalid; and blocking access of the user device to the secure resource when a predetermined number of passwords are determined to be invalid by the authentication device.
KARACHIWALA (US-10299118-B1): This prior art teaches of a request including a user identifier is received from a third party to authenticate an access attempt by a person. The input of the user identifier is not accompanied by a password. A listing of associated mobile devices is transmitted to the third party. The person selects a mobile device to which an authentication notification should be sent. The notification is pushed to the mobile device. A user of the device views the notification and verifies whether the access should be allowed or denied. If access should be allowed, a first one-time password (OTP) is generated and transmitted to an authentication server. The server generates a second OTP. If the second OTP matches the first OTP, the server notifies the third party that access should be permitted. If the second OTP does not match the first OTP, the server notifies the third party that access should be blocked.
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). 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 AFAQ ALI whose telephone number is (571)272-1571. The examiner can normally be reached Mon - Fri 7:30am - 5:30pm EST.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, ALI SHAYANFAR can be reached at (571) 270-1050. 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.
/A.A./
08/21/2026
/AFAQ ALI/Examiner, Art Unit 2434
/ALI SHAYANFAR/Supervisory Patent Examiner, Art Unit 2434
Prosecution Insights