DETAILED ACTION
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
This Office Action is in response to the communication filed on 03/19/2025.
Claims 21-24 have been canceled. Claims 25-27 have been added. Claims 1-20 and 25-27 are pending.
Response to Arguments
Applicant's Remarks filed on 03/19/2025 have been fully considered.
The objection to claim 14 presented in the previous Office action has been withdrawn in view of Applicant’s amendments of the claim.
The rejection of claim 20 under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite as presented in the previous Office action has been withdrawn in view of Applicant’s amendment of the claim.
The rejection of claims 1-7 and 17-20 under 35 U.S.C. 101 has been withdrawn in view of Applicant’s amendment of the claims.
In response to Applicant’s argument on pages 8-10 of Remarks that Stelzner is not directed to cryptographic tokens and Stelzner does not describe a parent cryptographic token and a child cryptographic token and the relationship between the parent and child tokens, Examiner respectfully disagrees for the following reasons. First, since the claims do not recite the specifics (e.g., the type and structure) of the term “cryptographic token”, using the broadest reasonable interpretation, this term covers any type of cryptographically secured data that proves identity, authorization or ownership. Second, Applicant mentioned that “a cryptographic token is a container or other partition of an HSM” referring to [0002] and [0028] of Applicant’s specification. Applicant further stated that “The difference between a cryptographic token and a certificate is further underscored by FIGS. 2 and 3 of the present application, which shows certificates (e.g., ‘EMV certificate’) as being cryptographic objects that are contained within cryptographic tokens”. However, it should be noted that these are just examples and the scopes of the claims are not limited to these examples. Furthermore, these features are not recited in the claims. Although the claims are interpreted in light of the specification, limitations from the specification are not read into the claims. See In re Van Geuns, 988 F.2d 1181, 26 USPQ2d 1057 (Fed. Cir. 1993). Third, Stelzner teaches digital certificates, each comprises a plurality of contents or objects and is used to prove ownership of a public key associated with that certificate. Stelzner further teaches certificate chains such as a full certificate chain comprising an ordered list of certificates including an end-entity (device) certificate, intermediate certificates that represent intermediate CA(s), and the certificate for the root CA and a shorter certificate chain comprising one or more certificates in the full certificate chain but less than the full certificate chain (e.g. [0030]-[0031]). In stelzner, each digital certificate is a cryptographically secured data proving that a public key belongs to a specific entity (device). It provides proof of ownership and identity used for authentication of the specific entity. Thus, each digital certificate is a cryptographic token. In addition, a higher-level certificate in a certificate chain corresponds to a parent cryptographic token and a lower-level certificate in the certificate chain corresponds to a child cryptographic token. The parent and child cryptographic tokens are related or associated due to being in the same certificate chain where the parent cryptographic token is at a higher level in the certificate chain than the child cryptographic token. For at least the above reasons, Stelzner is directed to cryptographic tokens and does describe a parent cryptographic token and a child cryptographic token and the relationship between the parent and child tokens.
In response to Applicant’s argument on page 10 of Remarks that Stelzner does not describe “wherein a session established with the child cryptographic token provides access to at least some of the plurality of child cryptographic objects and at least some the plurality of parent cryptographic objects”, Examiner respectfully disagrees for the following reasons. First, the claims only recite “a session established with the child cryptographic token provides access” and do not further clarify the term “session”, for example, the type of the session, the steps in establishing the session, the session is between or among which entities, and how access is provided for example, the type of access, provided by which entity and to whom. Thus, using the broadest reasonable interpretation, the current claim language “a session established with the child cryptographic token provides access” covers any type of session established using any method directly or indirectly based on the child cryptographic token provides any type of access to any entity. Second, Stelzner teaches “device 104 may establish a first tunnel with HSM 106 and may send encrypted data with the shorter certificate chain to HSM 106” (e.g., [0032]) and “subsequent to receiving the shorter certificate from device 104, HSM 106 is configured to authenticate device 104 and to decrypt the data. HSM 106 may establish a second tunnel with device 102, associate the data with the longer certificate chain, and send the data to device 102. Device 102 can thereafter authenticate device 104 and decrypt the data sent from device 104 via HSM 106 because device 102 includes the full certificate chain as provided in the information sent from HSM 106” (e.g., [0033]). Thus, Stelzner teaches the establishment of the session between HSM 106 and device 102 was triggered by the shorter certificate (chain) including the lower level certificate (the child cryptographic token) that authenticated device 104 to HSM 106 wherein access to the full certificate chain including the lower level certificate comprising the plurality of contents (the child cryptographic objects) and the higher level certificate comprising the plurality of contents (the parent cryptographic objects) is provided in HSM 106 to send to device 102 and provided in device 102 for authenticating device 104. For at least the above reasons, Stelzner does describe “wherein a session established with the child cryptographic token provides access to at least some of the plurality of child cryptographic objects and at least some the plurality of parent cryptographic objects”.
In addition, in response to Applicant's argument that the remaining dependent claims are not anticipated by Stelzner because they depend from independent claims that are not anticipated by Stelzner, Examiner respectfully disagrees since the base claims from which they depend are anticipated by Stelzner for at least the reasons explained above.
Claim Objections
Claim 1 is objected to because of the following informalities:
“an HSM” in claim 1 should read “the HSM”.
“a second cryptographic child token” in claim 2 should read “a second child cryptographic token”.
Appropriate correction is required.
Claim Rejections - 35 USC § 102
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale or otherwise available to the public before the effective filing date of the claimed invention.
Claims 1-20 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Stelzner et al. (US 2016/0065537).
Claim 1, Stelzner teaches:
A system for managing a cryptographic token hierarchy within a hardware security module (HSM), the system comprising:
an HSM including a memory, the memory storing: (e.g., [0032], “HSM 106 is configured to store all the certificates needed in certificate chain(s)”)
a parent cryptographic token containing a plurality of parent cryptographic objects; (e.g., [0030], “Digital certificates are verified using a chain of trust, wherein a digital certificate may be used prove ownership of a public key associated with the certificate. A trust anchor for a digital certificate is a root Certificate Authority (CA). The digital certificate includes, among other information, information about one or more entities that verified the certificate's contents. The chain of trust of a certificate chain is an ordered list of certificates including an end-entity (device) certificate, intermediate certificates that represent intermediate CA(s), and the certificate for the root CA. The chain of trust enables a relying device to verify that a certificate for a sending device and all intermediate and root certificates in the chain are trustworthy” [0031], “one or more devices in system 100, for example, device 104…a communication device with limitations on certificate storage may be allowed to store one or more certificates in a chain that is less than the full chain of trust. Consider, for example, that device 104 may be configured to store an end entity certificate and its immediate issuing certificate (CA1), even when there are more intermediate certificates in the chain of trust all the way up to the root CA…there may be system infrastructure with more resources that may be configured to store a full chain of trust, i.e., the certificate chain from an end entity up to the root CA…by storing a shorter certificate chain than the full chain of trust, device 104 is limited in its interoperability with devices that store the entire chain of trust” [0032], “Consider also, for example, that device 102 is configured to store the full chain of trust. Even if device 102 and device 104 are operating on the same security level, device 102 and device 104 will unable to communicate directly because they store different chains of trust. Therefore, device 104 may establish a first tunnel with HSM 106 and may send encrypted data with the shorter certificate chain to HSM 106. HSM 106 is configured to store all the certificates needed in certificate chain(s). HSM 106 may validate the certificates up the chain(s)” [0033], “subsequent to receiving the shorter certificate from device 104…HSM 106 may establish a second tunnel with device 102, associate the data with the longer certificate chain, and send the data to device 102…device 102 includes the full certificate chain as provided in the information sent from HSM 106…HSM 106 serves as an interpreter, wherein device 104 establishes a first tunnel with HSM 106, device 104 sends data to HSM 106 via the first tunnel…HSM 106 sends the converted data to device 102 on the second tunnel”: any certificate chain (shorter, longer, or full) comprises a plurality of certificates, including at least one higher-level certificate which corresponds to a parent cryptographic token containing higher-level certificate contents and at least one lower-level certificate which corresponds to a child cryptographic token containing lower-level certificate contents)
a child cryptographic token containing a plurality of child cryptographic objects, the child cryptographic token being associated with the parent cryptographic token; (e.g., [0030], “Digital certificates are verified using a chain of trust, wherein a digital certificate may be used prove ownership of a public key associated with the certificate. A trust anchor for a digital certificate is a root Certificate Authority (CA). The digital certificate includes, among other information, information about one or more entities that verified the certificate's contents. The chain of trust of a certificate chain is an ordered list of certificates including an end-entity (device) certificate, intermediate certificates that represent intermediate CA(s), and the certificate for the root CA. The chain of trust enables a relying device to verify that a certificate for a sending device and all intermediate and root certificates in the chain are trustworthy” [0031], “one or more devices in system 100, for example, device 104…a communication device with limitations on certificate storage may be allowed to store one or more certificates in a chain that is less than the full chain of trust. Consider, for example, that device 104 may be configured to store an end entity certificate and its immediate issuing certificate (CA1), even when there are more intermediate certificates in the chain of trust all the way up to the root CA…there may be system infrastructure with more resources that may be configured to store a full chain of trust, i.e., the certificate chain from an end entity up to the root CA…by storing a shorter certificate chain than the full chain of trust, device 104 is limited in its interoperability with devices that store the entire chain of trust” [0032], “Consider also, for example, that device 102 is configured to store the full chain of trust. Even if device 102 and device 104 are operating on the same security level, device 102 and device 104 will unable to communicate directly because they store different chains of trust. Therefore, device 104 may establish a first tunnel with HSM 106 and may send encrypted data with the shorter certificate chain to HSM 106. HSM 106 is configured to store all the certificates needed in certificate chain(s). HSM 106 may validate the certificates up the chain(s)” [0033], “subsequent to receiving the shorter certificate from device 104…HSM 106 may establish a second tunnel with device 102, associate the data with the longer certificate chain, and send the data to device 102…device 102 includes the full certificate chain as provided in the information sent from HSM 106…HSM 106 serves as an interpreter, wherein device 104 establishes a first tunnel with HSM 106, device 104 sends data to HSM 106 via the first tunnel…HSM 106 sends the converted data to device 102 on the second tunnel”: any certificate chain (shorter, longer, or full) comprises a plurality of certificates, including at least one higher-level certificate which corresponds to a parent cryptographic token containing higher-level certificate contents and at least one lower-level certificate which corresponds to a child cryptographic token containing lower-level certificate contents)
wherein a session established with the child cryptographic token provides access to at least some of the plurality of child cryptographic objects and at least some of the plurality of parent cryptographic objects. (e.g., [0032] “Even if device 102 and device 104 are operating on the same security level, device 102 and device 104 will unable to communicate directly because they store different chains of trust. Therefore, device 104 may establish a first tunnel with HSM 106 and may send encrypted data with the shorter certificate chain to HSM 106. HSM 106 is configured to store all the certificates needed in certificate chain(s). HSM 106 may validate the certificates up the chain(s), and then vouch or re-sign the certificate with its own certificate (to make the chain of trust a “chain of one” so that device 104 can validate the chain)” [0033] “subsequent to receiving the shorter certificate from device 104, HSM 106 is configured to authenticate device 104 and to decrypt the data. HSM 106 may establish a second tunnel with device 102, associate the data with the longer certificate chain, and send the data to device 102. Device 102 can thereafter authenticate device 104 and decrypt the data sent from device 104 via HSM 106 because device 102 includes the full certificate chain as provided in the information sent from HSM 106”)
Claim 2, Stelzner teaches:
Wherein the memory of the HSM further stores a second cryptographic child token associated with the parent cryptographic token, the second child cryptographic token containing a second plurality of child cryptographic objects. (e.g., [0030]-[0033]: another lower-level certificate in the certificate chain containing the another lower-level certificate contents)
Claim 3, Stelzner teaches:
wherein a session established with the second child cryptographic token provides access to at least some of the second plurality of child cryptographic objects and at least some of the plurality of parent cryptographic objects. (e.g., [0013], “enabling direct communications between devices operating at different security levels” [0030]-[0033]: another session established with the shorter certificate chain not involving device 102)
Claim 4, Stelzner teaches:
wherein the plurality of child cryptographic objects of the child cryptographic token are inaccessible via the session established with the second child token. (e.g., [0030]-[0033]: the contents of the lower-level certificate in the certificate chain are inaccessible to device 102 via the other session where device 102 is not involved)
Claim 5, Stelzner teaches:
Wherein the memory of the HSM further stores: a second parent cryptographic token containing a second plurality of parent cryptographic objects; and (e.g., [0030]-[0033]: another higher-level certificate in the certificate chain containing the another higher-level certificate contents)
a third child cryptographic token containing a third plurality of child cryptographic objects, the third child cryptographic token being associated with the second parent cryptographic token. (e.g., [0030]-[0033]: another lower-level certificate in the certificate chain containing the another lower-level certificate contents)
Claim 6, Stelzner teaches:
wherein the parent cryptographic token is associated with a first service bureau, the child cryptographic token is associated with a first card issuing institution, and the second child cryptographic token is associated with a second card issuing institution different from the first card issuing institution. (e.g., [0030]-[0031]: the higher-level certificate was issued by a certificate authority (e.g., root or intermediate CA), the lower-level certificate was issued by another certificate authority (e.g., another intermediate CA), and the other lower-level certificate was issued by another certificate authority (e.g., a different intermediate CA))
Claim 7, Stelzner teaches:
wherein the parent cryptographic token is a separate token from the child cryptographic token within the memory of the HSM. (e.g., [0032])
Claim 8, Stelzner teaches:
A method of managing tokens used at a hardware security module, the method comprising:
receiving a session connection request from a client associated with a child token, the child token containing a plurality of child cryptographic objects; and (e.g., [0030], “Digital certificates are verified using a chain of trust, wherein a digital certificate may be used prove ownership of a public key associated with the certificate. A trust anchor for a digital certificate is a root Certificate Authority (CA). The digital certificate includes, among other information, information about one or more entities that verified the certificate's contents. The chain of trust of a certificate chain is an ordered list of certificates including an end-entity (device) certificate, intermediate certificates that represent intermediate CA(s), and the certificate for the root CA. The chain of trust enables a relying device to verify that a certificate for a sending device and all intermediate and root certificates in the chain are trustworthy” [0031], “one or more devices in system 100, for example, device 104…a communication device with limitations on certificate storage may be allowed to store one or more certificates in a chain that is less than the full chain of trust. Consider, for example, that device 104 may be configured to store an end entity certificate and its immediate issuing certificate (CA1), even when there are more intermediate certificates in the chain of trust all the way up to the root CA…there may be system infrastructure with more resources that may be configured to store a full chain of trust, i.e., the certificate chain from an end entity up to the root CA…by storing a shorter certificate chain than the full chain of trust, device 104 is limited in its interoperability with devices that store the entire chain of trust” [0032], “Even if device 102 and device 104 are operating on the same security level, device 102 and device 104 will unable to communicate directly because they store different chains of trust. Therefore, device 104 may establish a first tunnel with HSM 106 and may send encrypted data with the shorter certificate chain to HSM 106”)
in response to the session connection request, establishing a session with the child token, thereby providing access, via the session, to at least some of the plurality of child cryptographic objects and one or more parent cryptographic objects contained within a parent token associated with the child token. (e.g., [0032], “Even if device 102 and device 104 are operating on the same security level, device 102 and device 104 will unable to communicate directly because they store different chains of trust. Therefore, device 104 may establish a first tunnel with HSM 106 and may send encrypted data with the shorter certificate chain to HSM 106” [0033], “subsequent to receiving the shorter certificate from device 104, HSM 106 is configured to authenticate device 104 and to decrypt the data. HSM 106 may establish a second tunnel with device 102, associate the data with the longer certificate chain, and send the data to device 102. Device 102 can thereafter authenticate device 104 and decrypt the data sent from device 104 via HSM 106 because device 102 includes the full certificate chain as provided in the information sent from HSM 106”)
Claim 9, Stelzner teaches:
wherein the session has a security context, and wherein the at least some of the plurality of child cryptographic objects is associated with the security context. (e.g., [0030]-[0033])
Claim 10, Stelzner teaches:
wherein at least one child cryptographic object is included in the child token that is not associated with the security context, the at least one child cryptographic object being inaccessible via the session. (e.g., [0013], [0031])
Claim 11, Stelzner teaches:
wherein the one or more parent cryptographic objects are associated with the security context of the session, and at least one parent cryptographic object included in the parent token other than the one or more parent cryptographic objects is not associated with the security context and therefore inaccessible via the session. (e.g., [0013], [0031])
Claim 12, Stelzner teaches:
receiving a second session connection request from a second client associated with a second child token, the second child token containing a second plurality of child cryptographic objects, the second client being unaffiliated with the client; and (e.g., [0013], [0030]-[0033])
in response to the second session connection request, establishing a session with the second child token, thereby providing access, via the session, to at least some of the second plurality of child cryptographic objects and the one or more parent cryptographic objects contained within the parent token, the parent token being associated with both the child token and the second child token. (e.g., [0030]-[0033])
Claim 13, Stelzner teaches:
at the hardware security module: receiving a second session connection request from a second client associated with the parent token, the session request being associated with a security context associated with a security officer associated with the parent token; and (e.g., [0030]-[0033])
within a session established with the parent token in response to the second session connection request, receiving authorization from the second client to authorize inheritance of the one or more parent cryptographic objects of the parent token by one or more child tokens. (e.g., [0030]-[0033])
Claim 14, Stelzner teaches:
at the hardware security module: receiving a session connection request associated with the child token, the session connection request being associated with a security context associated with a security officer associated with the child token; and (e.g., [0032]-[0033])
within a session established with the child token in response to the second session connection request, receiving authorization to associate the child token with the parent token. (e.g., [0032]-[0033])
Claim 15, Stelzner teaches:
wherein the parent token is not modifiable from within the session established with the child token. (e.g., [0030]-[0031])
Claim 16, Stelzner teaches:
wherein changes to the parent token made concurrently with an active session with the child token are accessible during the active session. (e.g., [0032]-[0033])
Claim 17, Stelzner teaches:
A system comprising:
a hardware security (HSM) including a memory, the memory storing: (e.g., [0032], “HSM 106 is configured to store all the certificates needed in certificate chain(s)”)
a parent cryptographic token, the parent cryptographic token containing a plurality of parent cryptographic objects; and (e.g., [0030], “Digital certificates are verified using a chain of trust, wherein a digital certificate may be used prove ownership of a public key associated with the certificate. A trust anchor for a digital certificate is a root Certificate Authority (CA). The digital certificate includes, among other information, information about one or more entities that verified the certificate's contents. The chain of trust of a certificate chain is an ordered list of certificates including an end-entity (device) certificate, intermediate certificates that represent intermediate CA(s), and the certificate for the root CA. The chain of trust enables a relying device to verify that a certificate for a sending device and all intermediate and root certificates in the chain are trustworthy” [0031], “one or more devices in system 100, for example, device 104…a communication device with limitations on certificate storage may be allowed to store one or more certificates in a chain that is less than the full chain of trust. Consider, for example, that device 104 may be configured to store an end entity certificate and its immediate issuing certificate (CA1), even when there are more intermediate certificates in the chain of trust all the way up to the root CA…there may be system infrastructure with more resources that may be configured to store a full chain of trust, i.e., the certificate chain from an end entity up to the root CA…by storing a shorter certificate chain than the full chain of trust, device 104 is limited in its interoperability with devices that store the entire chain of trust” [0032], “Consider also, for example, that device 102 is configured to store the full chain of trust. Even if device 102 and device 104 are operating on the same security level, device 102 and device 104 will unable to communicate directly because they store different chains of trust. Therefore, device 104 may establish a first tunnel with HSM 106 and may send encrypted data with the shorter certificate chain to HSM 106. HSM 106 is configured to store all the certificates needed in certificate chain(s). HSM 106 may validate the certificates up the chain(s)” [0033], “subsequent to receiving the shorter certificate from device 104…HSM 106 may establish a second tunnel with device 102, associate the data with the longer certificate chain, and send the data to device 102…device 102 includes the full certificate chain as provided in the information sent from HSM 106…HSM 106 serves as an interpreter, wherein device 104 establishes a first tunnel with HSM 106, device 104 sends data to HSM 106 via the first tunnel…HSM 106 sends the converted data to device 102 on the second tunnel”: any certificate chain (shorter, longer, or full) comprises a plurality of certificates, including at least one higher-level certificate which corresponds to a parent cryptographic token containing higher-level certificate contents and at least one lower-level certificate which corresponds to a child cryptographic token containing lower-level certificate contents)
a child cryptographic token, the child cryptographic token being associated with the parent cryptographic token and containing a plurality of child cryptographic objects; (e.g., [0030], “Digital certificates are verified using a chain of trust, wherein a digital certificate may be used prove ownership of a public key associated with the certificate. A trust anchor for a digital certificate is a root Certificate Authority (CA). The digital certificate includes, among other information, information about one or more entities that verified the certificate's contents. The chain of trust of a certificate chain is an ordered list of certificates including an end-entity (device) certificate, intermediate certificates that represent intermediate CA(s), and the certificate for the root CA. The chain of trust enables a relying device to verify that a certificate for a sending device and all intermediate and root certificates in the chain are trustworthy” [0031], “one or more devices in system 100, for example, device 104…a communication device with limitations on certificate storage may be allowed to store one or more certificates in a chain that is less than the full chain of trust. Consider, for example, that device 104 may be configured to store an end entity certificate and its immediate issuing certificate (CA1), even when there are more intermediate certificates in the chain of trust all the way up to the root CA…there may be system infrastructure with more resources that may be configured to store a full chain of trust, i.e., the certificate chain from an end entity up to the root CA…by storing a shorter certificate chain than the full chain of trust, device 104 is limited in its interoperability with devices that store the entire chain of trust” [0032], “Consider also, for example, that device 102 is configured to store the full chain of trust. Even if device 102 and device 104 are operating on the same security level, device 102 and device 104 will unable to communicate directly because they store different chains of trust. Therefore, device 104 may establish a first tunnel with HSM 106 and may send encrypted data with the shorter certificate chain to HSM 106. HSM 106 is configured to store all the certificates needed in certificate chain(s). HSM 106 may validate the certificates up the chain(s)” [0033], “subsequent to receiving the shorter certificate from device 104…HSM 106 may establish a second tunnel with device 102, associate the data with the longer certificate chain, and send the data to device 102…device 102 includes the full certificate chain as provided in the information sent from HSM 106…HSM 106 serves as an interpreter, wherein device 104 establishes a first tunnel with HSM 106, device 104 sends data to HSM 106 via the first tunnel…HSM 106 sends the converted data to device 102 on the second tunnel”: any certificate chain (shorter, longer, or full) comprises a plurality of certificates, including at least one higher-level certificate which corresponds to a parent cryptographic token containing higher-level certificate contents and at least one lower-level certificate which corresponds to a child cryptographic token containing lower-level certificate contents)
wherein a session established with the HSM to access the child token provides access to at least some of the plurality of child cryptographic objects and at least some of the plurality of parent cryptographic objects. (e.g., [0032] “Even if device 102 and device 104 are operating on the same security level, device 102 and device 104 will unable to communicate directly because they store different chains of trust. Therefore, device 104 may establish a first tunnel with HSM 106 and may send encrypted data with the shorter certificate chain to HSM 106. HSM 106 is configured to store all the certificates needed in certificate chain(s). HSM 106 may validate the certificates up the chain(s), and then vouch or re-sign the certificate with its own certificate (to make the chain of trust a “chain of one” so that device 104 can validate the chain)” [0033] “subsequent to receiving the shorter certificate from device 104, HSM 106 is configured to authenticate device 104 and to decrypt the data. HSM 106 may establish a second tunnel with device 102, associate the data with the longer certificate chain, and send the data to device 102. Device 102 can thereafter authenticate device 104 and decrypt the data sent from device 104 via HSM 106 because device 102 includes the full certificate chain as provided in the information sent from HSM 106”)
Claim 18, Stelzner teaches:
the memory of the HSM further storing: a grandchild cryptographic token, the grandchild cryptographic token being associated with the child cryptographic token and containing a plurality of grandchild cryptographic objects, wherein a session established with the grandchild cryptographic token provides access to one or more of the plurality of grandchild cryptographic objects, one or more of the plurality of child cryptographic objects, and one or more of the plurality of parent cryptographic objects. (e.g., [0030]-[0033])
Claim 19, Stelzner teaches:
the memory of the HSM further storing: a second child cryptographic token, the second child cryptographic token being associated with the parent cryptographic token and containing a second plurality of child cryptographic objects, wherein the grandchild cryptographic token is associated with both the child cryptographic token and the second child cryptographic token. (e.g., [0030]-[0033])
Claim 20, Stelzner teaches:
wherein a modification of one or more of the plurality of parent cryptographic objects is accessible via a session with any one of the child cryptographic token, the second child cryptographic token, or the grandchild cryptographic token. (e.g., [0032]-[0033])
Allowable Subject Matter
Claims 25-27 are objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to AMIE C LIN whose telephone number is (571)272-7752. The examiner can normally be reached M-F 9:00AM -5:00PM.
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, GELAGAY SHEWAYE can be reached at (571)272-4219. 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.
/AMIE C. LIN/Primary Examiner, Art Unit 2436
Prosecution Insights