DETAILED ACTION
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 . 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.
Claims 1-8 are pending.
Claims 1 and 5 are amended.
Response to Arguments
Applicant’s arguments filed 01/14/2026 have been fully considered.
Applicant argues:
Additionally, the keys exchanged in Farmer are not comparable to the user secret key generated in the trust zone, as set forth in claim 1”.
Examiner respectfully disagree because, “Diffe-Hellman and its application in security protocol” teaches claimed limitation “generating the user secret key” The claims as written do not prevent the prior art of record secret key. Applicant has failed to provide differences between the secret key and the secret cited in the prior art. The examiner has applied BRI for the secret key, whereas secret key is computed by Alice which is taught by “Diffe-Hellman and it’s application in security protocol” reference.
Applicant’s argument with respect to the amended limitation of “…trust zone which is a secure and logically isolated storage area in the storage device ” and “the user secret key being usable only in the trust zone” is moot in view of a new ground of rejection”.
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 and 5 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.
The term “usable only” in claim 1 and 5 is a relative term which renders the claim indefinite. The term “usable only” is not defined by the claim, the specification does not provide a standard for ascertaining the requisite degree, and one of ordinary skill in the art would not be reasonably apprised of the scope of the invention. Term “usable only” renders the meets renders the metes and bounds of the claim scope unclear.
Claims that depend on rejected base independent claims (i.e. claims 1 and 5) inherit by the nature of their dependency all rejections that are applied to their corresponding base claims. Thus, claims 2-4 and 6-8 are, in addition to any separate rejection disclosed above, also rejected using the same grounds of rejection as indicated in the rejection of their corresponding base claims above.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claim(s) 1-3, 5-7 are rejected under 35 U.S.C. 103 as being unpatentable over YOKOHARI YUMIKA et al. (JP 2018097034 A) (hereinafter “Yokohari” in view of “Ahmed, Maryam, et al. "Diffie-Hellman and its application in security protocols." International Journal of Engineering Science and Innovative Technology (IJESIT) 1.2 (2012): 69-73” (hereinafter “Diffie-Hellman and its application in security protocols”), Paczkowski et al. (U. S. Pat. No. 9,049,186 B1) (hereinafter “Paczkowski”); and further in view of Farmer et al. (U. S. Pat. No. 9,600,676 B1) (hereinafter “ Farmer”)
Regarding Claim 1, Yokohari teaches:
a data management server (Yokohari: [Page 2], The data management server 103 stores the secret data 532 (see FIG. 5))
and a client terminal, the data management server including an arithmetic device (Yokohari: [Page 23, paragraph [13], The basic arithmetic module 517 calculates an exclusive OR of the update difference key mask and the target record difference key mask 702 as shown in Expression (14).
and a storage device (Yokohari: [page 3, para 8](The storage device 203 stores data permanently. The storage device 203 may be, for example, anHDD (Hard Disk Drive), an SSD (Solid State Drive), or the like).
the data management server being configured to manage a database configured to store confidential data encrypted (Yokohari: [page 3, para 1], the data management server 103 converts the confidential data for output received from the registration client 101 into the confidential data 532 and stores it in the database 503 (see FIG. 5). In addition, the data management server 103 converts the confidential data 532 stored in the database 503 into confidential data for output. [Abstract]: Adata management server uses a master secret key to manage a database storing encrypted confidential data for management) based on a probabilistic encryption method using a master secret key (Yokohari: [Page 2, para 9], The registration client 101 generates secret data for output from plaintext data according to the probabilistic encryption method, and registers the secret data (management secret data) in the data management server 103. Here, the probabilistic encryption method is an encryption algorithm that generates random encrypted data in which the equivalence relation and the magnitude relation are concealed from plaintext data. In the stochastic encryption method, plaintext and ciphertext have a one-to-many correspondence).
and record the key management data as information for use in comparison processing (Yokohari: [Page 10, para 15], the overall processing module 511 adds a record to the key management information 505, and the user ID 701, the differential key mask 702, the search key 703, and the key version 704 of the added record are included in the user addition request. A user ID, a differential key mask, a search key 443, and a key version are set) for determining whether the user secret key is valid (Yokohari: [page 28, para [12], In the verification process, the key verification information included in the record corresponding to the first user matches the first key verification information included in the search request with reference to the first key management information. If it is determined that the user secret key for searching the first user is valid,).
Yokohari does not explicitly disclose:
the client terminal being configured to hold the public information and second secret information to be used in the Diffie-Hellman key exchange protocol,
the data management server being configured to:
generate the user secret key in the trust zone by using the public information, the first secret information, and the second public key, the user secret key being usable only in the trust zone;
generate, in a case where a request to generate a user secret key to be used to access the confidential data managed by the data management server is received from the client terminal, a first public key by using the public information and the first secret information
and transmit the first public key to the client terminal,
the client terminal being configured to:
generate the user secret key by using the public information, the second secret information, and the first public key
generate the user secret key in the trust zone by using the public information, the first secret information, and the second public key;
However, in an analogous art, “Diffie-hellman and its application in security protocols” disclose:
the client terminal being configured to hold the public information ((“Diffie-Hellman and its application in security protocols”): [Section II-Description], This procedure is called key agreement, meaning that the two parties are agreeing on a key to use. The protocol has two system parameters p and g. They are both public (=public information), and may be used by all users in a system. The first of these, parameter p, is a randomly selected prime number (hence “p”) while parameter g (this time for “generator”) is an integer less than p, [Table 1], Alice and Bob agree on two numbers:
p and g
p is a large prime number
g is the generator, or the base)
and second secret information to be used in the Diffie-Hellman key exchange protocol the data management server being configured to: ((“Diffie-Hellman and its application in security protocols”): [Table 1], Alice privately picks a secret number a Alice’s secret number = a; Bob privately picks a secret number b Bob’s secret number = b (a and b both are secret information); [Table 1], Bob privately picks a secret number b Bob’s secret number = b; [Table 1], Alice and Bob exchange their public keys, to be used for private generations of a common secret key.
(Alice knows p, g, a, x, y)
(Bob knows p, g, b, x, y)).
generate, in a case where a request to generate a user secret key to be used to access the confidential data managed by the data management server is received from the client terminal, a first public key by using the public information and the first secret information ((“Diffie-Hellman and its application in security protocols”): [Table], Alice computes her public key
x = g a mod p
Alice’s public number = x)
and transmit the first public key to the client terminal ((“Diffie-Hellman and its application in security protocols”): [Page 70, para 1, line 6], To proceed, the parties will send their public key to one another, in a process of key exchange…[Table 1], Alice and Bob exchange their public keys, to be used for private generations of a common secret key.
(Alice knows p, g, a, x, y)
(Bob knows p, g, b, x, y)),
the client terminal being configured to: generate the user secret key by using the public information, the second secret information, and the first public key ((“Diffie-Hellman and its application in security protocols”): [Table 1], Alice computes the secret key
ka = y a mod p
ka = (g b mod p) a mod p
ka = (g b) a mod p
ka = g b a mod p)
generate a second public key by using the public information and the second secret information (((“Diffie-Hellman and its application in security protocols”): [Table 1], Bob computes his public key y = g b mod p Bob’s public number = y)
and transmit the second public key to the data management server to (((“Diffie-Hellman and its application in security protocols”): [Table], Alice and Bob exchange their public keys, to be used for
private generations of a common secret key.
(Alice knows p, g, a, x, y)
(Bob knows p, g, b, x, y)),
generate the user secret key in the trust zone by using the public information, the first secret information, and the second public key (“Diffie-Hellman and its application in security protocols”): [Table], Alice computes the secret key
ka = y a mod p
ka = (g b mod p) a mod p
ka = (g b) a mod p
ka = g b a mod p (ka = secret key)
Bob computes the secret key
kb = x b mod p
kb = (g a mod p) b mod p
kb = (g a) b mod p
kb = g a b mod p (kb =Secrete key))
It would be obvious to a person having ordinary skill in the art, before the effective filing date of the invention, to modify Yokohari’s method of using probabilistic encryption method to encrypt the confidential data using master secret key by applying “Diff-Hellman and it’s application in security protocols’s” method of generating public key and exchanging generated public key, and generating secret key, in order prevent access to the confidential information from unauthorized users. The motivation is to prevent confidential data from undergoing unwanted changes and ensure that it is available to it’s intended users. (“Diff-Hellman and it’s application in security protocols”: [Section 1, Introduction]).
The Yokohari in view of “Diff-Hellman and it’s application in security protocols” does not explicitly teach:
the arithmetic device having a function for generating a trust zone which is secure and logically isolated in the storage device,
the trust zone storing the master secret key as well as public information and first secret information to be used in a Diffie-Hellman key exchange protocol,
the data management server being configured to: store the second public key in the trust zone;
generate, in the trust zone, key management data for managing the user secret key;
However, in an analogous art, Paczkowski teaches:
the arithmetic device having a function for generating a trust zone which is secure and logically isolated storage area in the storage device (Paczkowski: [Col 6, lines 50-68], (28) In an embodiment, the trusted security zone (=logically isolated storage area) 104 may be provided in a secure area of a processor and/or memory chip shared with the permissive sector 108 or in a separate processor and/or memory chip(=storage device). The trusted security zone 104 may be provided as what may be conceptualized as "invisible space" In an embodiment, at least some of the memory addresses occupied by the trusted security zone 104 may be inaccessible to device applications 110 executing out of permissive sector 108…the trusted security zone 104 may encapsulate a trusted execution environment (TEE), for example conforming at least partially to the Global Platform 2.0 or later revision trusted execution environment standard…)
the user secret key being usable only in the trust zone (Paczkowski: [Col 9, lines 8-9], The user specific key (=user secret key) 116 may then be stored in the trusted security zone 104 of the mobile device 102. [Col 5, lines 45-50], Placing the trusted security zone in the secure partition and restricting access from the normal partition protects against software and basic hardware attacks. Hardware logic ensures that no secure partition resources can be accessed by the normal partition components or applications. Examiner’s Note: The term “Usable” does not mean it is being used in trust zone, it means it could be used in the trust zone)
A person having ordinary skill in the art, before the effective filing date of the invention, would have found it obvious to modify Yokohari in view of “Diff-Hellman and its application in security protocols” by applying the well-known technique as disclosed by Paczkowski of providing trusted security zone in order to restricting access from the normal partition protects against software and basic hardware attacks. The motivation is providing increased security and to raise the level of difficulty for nefarious actors attempting to access the confidential information (Paczkowski:[Col 1, lines 29-31]).
The Yokohari in view of “Diff-Hellman and its application in security protocols” and Paczkowski does not explicitly disclose:
the trust zone storing the master secret key as well as public information and first secret information to be used in a Diffie-Hellman key exchange protocol;
the data management server being configured to: store the second public key in the trust zone;
generate, in the trust zone, key management data for managing the user secret key.
However, in an analogous art, Farmer teaches:
the trust zone storing the master secret key as well as public information and first secret information to be used in a Diffie-Hellman key exchange protocol (Farmer: [Col 5, lines 3-4], the wearable device can store multiple public keys for communicating with multiple entities. [Col 20, lines 41-48], (112) In other scenarios, wearable device 760a, perhaps using security application 1014, and application 1018 can use a key exchange, such as the Diffie-Hellman key exchange, to exchange keys, such as App1018Key and Key1018. The key-exchange protocol can be used to generate a shared key which can be used by both wearable device 760a and application 1018 for both encryption and decryption of messages/data)
the data management server being configured to: store the second public key in the trust zone (Farmer: [Col 5, lines 2-4], the wearable device can store multiple public keys for communicating with multiple entities. [Col 16, lines 46-58], (90) Scenario 1100 begins with application 1016 sending authentication information (AuthInfo) message 1110 to wearable device 760a to initiate authentication of application 1016 to receive sensitive data. Authentication information message 1110 can include App1016, which is an identifier associated with application 1016, and Key1016, which is information about a key or other secret associated with application 1016. For example, Key1016 can be a public key associated with application 1016, a key generated by application 1016, a reference to a public key associated with application 1016, another key associated with application 1016, and/or some other information about a key or other secret associated with application 1016.)
generate, in the trust zone, key management data for managing the user secret key (Farmer: [Col 27, lines 59-60], generate OK Trust Zone message 1412, [Col 15, lines 62-63], the wearable computing device can be further configured to store non-sensitive information. [Col 16, lines 46-58], (90) Scenario 1100 begins with application 1016 sending authentication information (AuthInfo) message 1110 to wearable device 760a to initiate authentication of application 1016 to receive sensitive data. Authentication information message 1110 can include App1016, which is an identifier associated with application 1016, and Key1016, which is information about a key or other secret associated with application 1016. For example, Key1016 can be a public key associated with application 1016, a key generated by application 1016, a reference to a public key associated with application 1016, another key associated with application 1016, and/or some other information about a key or other secret associated with application 1016. [Col 17, lines 4-7], The key-exchange protocol can be used to generate and/or communicate a shared key (=user secret key) which can be used by both wearable device 760a and application 1016 for both encryption and decryption of messages/data).
A person having ordinary skill in the art, before the effective filing date of the invention, would have found it obvious to modify Yokohari in view of “Diff-Hellman and its application in security protocols” and Paczkowski by applying the well-known technique as disclosed by Farmer of a trust zone established in order to permit device-to-device communication. The motivation is to establish a securer wireless communication link between the wearable computing device and another device, any application on either device for communicating sensitive data between each other (Farmer: [Abstract]).
Regarding Claim 2, Yokohari in view of “Diff-Hellman and its application in security protocols”, Paczkowski and Farmer teaches:
The computer system of claim 1 (see rejection of claim 1 above),
wherein the data management server is configured to delete the user secret key from the trust zone after the key management data is recorded (Yokohari :[Page 5, para 12], The user secret key 404 is a secret key that can be added, deleted, and updated.).
Regarding Claim 3, Yokohari in view of “Diff-Hellman and its application in security protocols”, Paczkowski and Farmer teaches:
The computer system of claim 1 (see rejection of claim 1 above),
wherein the user secret key is a key which is valid only once (Yokohari: [Page 4, para 3], The user secret key 304 is a secret key that can be added, deleted, and updated. [Page 21, para 14], When the key management server 104 receives the user secret key update request, the key management server 104 generates a new user secret key 304 (step S1602). [Page 22, para 11], In FIG. 16, the user secret key update process is started upon transmission of a user secret keyupdate request from the management client 105, but the execution trigger is not limited to this. Forexample, a value indicating an expiration date is added to the user secret keys 304 and 404, and theregistration client 101 and the search client 102 transmit an update request for the user secret keys304 and 404 whose expiration date has passed to the key management server 104.).
Regarding claim 5, this claim contains identical limitations found within that of claim 1 above albeit directed to a different statutory category (method medium). For this reason the same grounds of rejection are applied to claim 5.
Regarding claim 6, this claim contains identical limitations found within that of claim 2 above albeit directed to a different statutory category (method medium). For this reason the same grounds of rejection are applied to claim 6.
Regarding claim 7, this claim contains identical limitations found within that of claim 3 above albeit directed to a different statutory category (method medium). For this reason the same grounds of rejection are applied to claim 7.
Claim(s) 4 and 8 are rejected under 35 U.S.C. 103 as being unpatentable over YOKOHARI YUMIKA et al. (JP 2018097034 A) (hereinafter “Yokohari” in view of “Ahmed, Maryam, et al. "Diffie-Hellman and its application in security protocols." International Journal of Engineering Science and Innovative Technology (IJESIT) 1.2 (2012): 69-73” (hereinafter “Diffie-Hellman and it’s application in security protocols”) and Paczkowski et al. (U. S. Pat. No. 9,049,186 B1) (hereinafter “Paczkowski”) and Farmer et al. (U. S. Pat. No. 9,600,676 B1) (hereinafter “ Farmer”); and further in view of Campagna (U. S. PGPub. No. 2017/0171174 A1) (hereinafter “Campagna”)
Regarding Claim 4, Yokohari in view of “Diff-Hellman and it’s application in security protocols”, Paczkowski and Farmer teaches:
The computer system of claim 1 (see rejection of claim 1 above),
The above cited combination of Yokohari in view of “Diff-Hellman and it’s application in security protocols”, Paczkowski and Farmer does not explicitly disclose:
and encrypt the registered user management data and register the encrypted registered user management data in the data management server, and wherein the data management server is configured to: receive input of checked user management data in a case where a request to generate the user secret key is received;
and determine whether the user who has requested generation of the user secret key is a valid user based on the encrypted checked user management data and the encrypted registered user management data.
However, in an analogous art, Campagna teach:
wherein the client terminal is configured to: receive, from a user operating the client terminal, input of registered user management data for checking a validity of the user (Campagna: [0043], The cryptography service may have a set of client master keys wherein each client master key is associated and owned by a particular client. The client master keys may be associated with their respective clients as part of a registration process where the cryptography service establishes a trust relationship with the registrant, for example, by requiring the registrant to enter a password (=receiving input), provide a security token, or provide other proof of the identity of the registrant to prevent spoofing attacks);
and encrypt the registered user management data and register the encrypted registered user management data in the data management server, and wherein the data management server is configured to (Campagna: [0032], data to encrypt, a key identifier for uniquely identifying a cryptographic key that may be used to encrypting the data, an encryption context of labeled metadata describing the data to be encrypted, and an optional parameter for additional authenticated data (AAD) [0078], the cryptography service may support at least two operations—(1) generating a data key and (2) performing authenticated encryption of data.):
receive input of checked user management data in a case where a request to generate the user secret key is received (Campagna: [0043], The cryptography service may have a set of client master keys wherein each client master key is associated and owned by a particular client. The client master keys may be associated with their respective clients as part of a registration process where the cryptography service establishes a trust relationship with the registrant, for example, by requiring the registrant to enter a password (=receiving input), provide a security token, or provide other proof of the identity of the registrant to prevent spoofing attacks);
and determine whether the user who has requested generation of the user secret key is a valid user based on the encrypted checked user management data and the encrypted registered user management data (Campagna: [0022] As an example, two computer systems establish a cryptographically protected communication session where a partially trusted third party is utilized to establish a trust relationship between the two computer systems…the cryptography service may be trusted to generate digital signatures and to verify whether a purportedly authentic digital signature is indeed authentic).
A person having ordinary skill in the art, before the effective filing date of the invention, would have found it obvious to modify Yokohari in view of “Diff-Hellman and its application in security protocols”, Paczkowski and Farmer by applying the well-known technique as disclosed by Campagna of the registrant to enter a password (=receiving input), provide a security token, or provide other proof of the identity of the registrant to prevent spoofing attacks. The motivation is to Two or more clients may utilize a cryptography service to perform certain authentication and verification operations to establish a secure communication session, while simultaneously denying the cryptography service access to the secure communication session (Campagna: [Abstract])
Regarding claim 8, this claim contains identical limitations found within that of claim 4 above albeit directed to a different statutory category (method medium). For this reason the same grounds of rejection are applied to claim 8.
Conclusion
The prior art made of record and not relied upon is considered pertinent to a disclosure. Refer to PTO-892, Notice of References Cited for a listing of analogous art.
U. S. PGPub. No. 2017/0141926 A1 (Xu et al.): Methods, systems, and devices are provided for authenticating API messages using PKI-based authentication techniques. A client system can generate a private/public key pair associated with the client system and sign an API message using the private key of the private/public key pair and a PKI-based cryptographic algorithm, before sending the signed API message to a server system. The server system (e.g., operated by a service provider) can authenticate the incoming signed API message using a proxy authenticator located in less trusted zone (e.g., a perimeter network) of the server system. In particular, the proxy authenticator can be configured to verify the signature of the signed API message using the public key corresponding to the private key and the same cryptographic algorithm. The authenticated API message can then be forwarded to a more trusted zone (e.g., an internal network) of the server system for further processing.
U. S Pat. No. 11,483,145 B2 (Matsui et al.): A key exchange device is provided that includes: a shared secret key storage in which shared secret information mk.sub.i.sup.k which is information different from a secret key of the key exchange device is stored; an authentication information addition unit that generates authentication information σ.sub.i, by which authentication is performed and falsification is detected, for key exchange information e.sub.i, which is output to the outside, by using the shared secret information mk.sub.i.sup.k; and an authentication information verification unit that receives key exchange information e.sub.s and authentication information σ.sub.s corresponding to the key exchange information e.sub.s from the outside, verifies the authentication information σ.sub.s using the shared secret information mk.sub.i.sup.k, and, if the authentication information σ.sub.s is not successfully verified, stops a key exchange, and the shared secret information mk.sub.i.sup.k is a value that is used in a generation process in a key exchange.
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 RUPALI DHAKAD whose telephone number is (571)270-3743. The examiner can normally be reached M-F 8:30-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, Alexander Lagor can be reached at 5712705143. 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.
/R.D./Examiner, Art Unit 2437
/ALI S ABYANEH/Primary Examiner, Art Unit 2437