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.
Claim Interpretation
Reference characters within the claims corresponding to elements recited in the detailed specification/drawings may be used, however, their use is considered as having no effect on the scope of the claims. MPEP 608.01(m).
Claim Objections
The numbering of claims is not in accordance with 37 CFR 1.126 which requires the original numbering of the claims to be preserved throughout the prosecution. When claims are canceled, the remaining claims must not be renumbered. When new claims are presented, they must be numbered consecutively beginning with the number next following the highest numbered claims previously presented (whether entered or not).
Misnumbered claim been renumbered as 13. After claim 12, next claim number should be 13 and its subsequent claim should be claim 14. Appropriate number sequence is required.
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-6 and 11-12 are rejected under 35 U.S.C. 103 as being unpatentable over Norum (U. S. PGPub. No. 2020/0059373 A1) (hereinafter “Norum”) in view of Khan (U. S. PGPub. No. 2016/0286391 A1) (hereinafter “Khan”); and further in view of Hamid (U. S. PGPub. No. 2013/0179676 A1) (hereinafter “Hamid”) and Klawe et al. (U. S. PGPub. No. 2019/0207953 A1) (hereinafter “Klawe”)
Regarding Claim 1, Norum teaches:
A system for securely configuring a Hardware Server Module (HSM) initially without prior customer network configuration on that HSM, comprising (Norum: [0030], The virtual HSM may transparently wrap the scaling, replacement, and configuration of a fleet of HSMs by providing a set of cryptographic module interfaces in accordance with those provided by a traditional HSM. In this way, the client 102 may interact with the virtual HSM in the same or similar manner as a traditional HSM, and the client will not need to configure the scaling, replacement, configuration, etc. of the virtual HSM's underlying fleet of HSMs.)
a computer (3) or mobile device within a protected environment (200) for programming a secure element (5) (Norum: [0053], In some embodiments, configuration data 222 may include data that may be used by the HSM 212A (=secure element) to communicate with other HSMs in the fleet 204. The configuration data may include a list of network addresses for all HSMs in the fleet).
wherein the memory includes computer instructions which when executed by the one or more processors causes the one or more processors to perform the operations (250) of (Norum: [0098] Each server typically will include an operating system that provides executable program instructions for the general administration and operation of that server and typically will include a computer-readable storage medium (e.g., a hard disk, random access memory, read only memory, etc.) storing instructions that, when executed (i.e., as a result of being executed) by a processor of the server, allow the server to perform its intended functions):
receiving (260) a set of Internet Protocol (IP) addresses (Norum: [0081], In some embodiments, at least one HSM in the fleet receives 716 the HSM 706 network address (=IP address) and adds information related to the HSM 706 to its configuration data. [0034], Each HSM in the fleet may include a list of all HSMs in the fleet as well as information that may be used for an HSM in the fleet to communicate with one or more other HSMs in the fleet. For example, each HSM in the fleet may include a list of network addresses for each other HSM in the fleet. A network address may be an IP address, a media access control address, or other such information to identify an HSM on a network. HSMs in the fleet may also contain key material, such as cryptographic keys and digital certificates, that may be used as part of fulfilling requests made to the virtual HSM. [0053], The configuration data may include a list of network addresses for all HSMs in the fleet 204)
securely storing (262) the set of IP addresses in the secure element (5) (Norum: [0034], For example, each HSM in the fleet may include a list of network addresses (=IP addresses) for each other HSM in the fleet. A network address may be an IP address, a media access control address, or other such information to identify an HSM on a network);
and, a Hardware Server Module (HSM) in an onboarding environment (300) the HSM (10) comprising: (Norum: [0030], The virtual HSM may transparently wrap the scaling, replacement, and configuration of a fleet of HSMs by providing a set of cryptographic module interfaces in accordance with those provided by a traditional HSM. In this way, the client 102 may interact with the virtual HSM in the same or similar manner as a traditional HSM, and the client will not need to configure the scaling, replacement, configuration, etc. of the virtual HSM's underlying fleet of HSMs.), comprising one or more processors and memory coupled to the one or more processors (Norum: [0103], Where a system includes computerized devices, each such device can include hardware elements that may be electrically coupled via a bus, the elements including, for example, at least one central processing unit (“CPU” or “processor”), at least one input device (e.g., a mouse, keyboard, controller, touch screen, or keypad) and at least one output device (e.g., a display device, printer, or speaker). Such a system may also include one or more storage devices, such as disk drives, optical storage devices, and solid-state storage devices such as random access memory (“RAM”) or read-only memory (“ROM”), as well as removable media devices, memory cards, flash cards, etc),
wherein the memory includes computer instructions which when executed by the one or more processors causes the one or more processors to perform the operations (350) of (Norum: [0098] Each server typically will include an operating system that provides executable program instructions for the general administration and operation of that server and typically will include a computer-readable storage medium (e.g., a hard disk, random access memory, read only memory, etc.) storing instructions that, when executed (i.e., as a result of being executed) by a processor of the server, allow the server to perform its intended functions):
retrieving (358) the set of IP addresses in the secure element (5) associated with said HSM custom network configuration responsive to authenticating said secure element and authenticating said user (Norum: [0047], An HSM 212A and 212B of the fleet may include…and configuration data 222. [0053], The configuration data may include a list of network addresses for all HSMs in the fleet 204. [0081], In some embodiments, at least one HSM in the fleet receives 716 the HSM 706 network address (=IP address))
configuring (360) an initial network state of the HSM for external communication with the set of IP addresses (Norum: [0076] FIG. 6 illustrates an environment in which various embodiments can be implemented. The computing environment 600 illustrates a process for initializing and provisioning a virtual HSM).
Norum does not explicitly disclose below limitations
However, in an analogous art, Khan teaches:
authenticating (254) the secure element as a trusted device by way of a certificate (7) stored thereon (Khan: [0040] In these ways, electronic device 112 may certify that the secure element in electronic device 110 is valid);
authenticating (256) a user of the trusted device via the secure element (Khan: [0058], payment applet 236-1 may need to be activated and the authentication-complete flag may need to be set or enabled in secure element 230 (indicating that the user has been authenticated);
authenticating (354) the secure element as a trusted device to the HSM by way of the certificate stored thereon (Khan: [0040] In these ways, electronic device 112 may certify that the secure element in electronic device 110 is valid);
authenticating (356) a user of the secure element to the HSM (Khan: [0058], payment applet 236-1 may need to be activated and the authentication-complete flag may need to be set or enabled in secure element 230 (=indicating that the user has been authenticated);
It would be obvious to a person having ordinary skill in the art, before the effective filing date of the invention, to modify Norum’s method of initializing and provisioning a virtual HSM using IP addresses (network address) which is associated with each HSM by applying Khan’s method of Authenticating secure element and authenticating user of the secure element, in order to preventing secure-element-identifier spoofing by using a digital signature while communicating with the secure-element identifier (Khan: [0003]).
The Norum in view of Khan does not explicitly disclose below limitations:
However, in an analogous art, Hamid teaches:
establishing (258) a secure communication for programming the secure element responsive to authenticating said secure element and authenticating said user(Hamid: [0036], When a user wants to access data (e.g., encrypted data) from the cloud, a secure connection can be established between a user device, and the cloud hosted HSM, e.g., at 525. The HSM can include keys used to decrypt the user's data, and can act as the sole facilitator of accessing that data, e.g., at 530) responsive to user entry on the computer or mobile device for association with a HSM custom network configuration (Hamid: [0032] Exemplary embodiments of Cloud HSMs can include using the exemplary Cloud HSMs as PKI tokens 120. Organizations and/or users can then deploy any number of security functions, including, e.g., 2-Factor certificate based authentication for workstation, virtual private network (VPN) and single sign-on (SSO) logins, digital signatures for email and document signing, and/or desktop to desktop email encryption. [0034], Users or organizations can be provided the ability to control which endpoints are allowed to connect to a device. Further, enhancements to password authentication may also be required and/or encouraged, such as notifications to a user's smart phone or other device 110 or platform 410 when an attempt is being made to connect to an associated Cloud HSM 120, or the usage of the smart phone as a second factor of authentication);
A person having ordinary skill in the art, before the effective filing date of the invention, would have found it obvious to modify Norum in view of Khan by applying the well-known technique as disclosed by Hamid of detecting USB security device (=secure element) directly plugged into client machine. The motivation is to provide security for most device users and organizations ensuring data privacy, such as access passwords, biometric readers, hardware security tokens, digital certificates, encryption/decryption, secure socket communications, etc (Hamid: [0002]).
Norum in view of Khan and Hamid does not explicitly disclose:
detecting (352) a presence of the secure element (5) in a vicinity of computer or mobile device;
detecting (352) a presence of the secure element (5) in a vicinity of the HSM;
However, in an analogous art, Klawe disclose:
detecting (352) a presence of the secure element (5) in a vicinity of computer or mobile device (Klawe: [0068] The term “swipe” here refers to any manner of triggering (=detecting) a payment object reader to read data from a payment object, such as by dipping into, tapping, hovering, bringing in close contact (=vicinity) or passing the payment object into or through a payment object reader);
detecting (352) a presence of the secure element (5) in a vicinity of the HSM (Klawe: [0068] The term “swipe” here refers to any manner of triggering (=detecting) a payment object reader to read data from a payment object, such as by dipping into, tapping, hovering, bringing in close contact (=vicinity) or passing the payment object into or through a payment object reader).
A person having ordinary skill in the art, before the effective filing date of the invention, would have found it obvious to modify Norum in view of Khan and Hamid by applying the well-known technique as disclosed by Klawe of establishing communication path by inserting chip card into the EMV slot. The motivation is to determine whether a payment terminal has been tampered with based on a comparison of attestation data received from the payment terminal (Klawe: [Abstract]).
Regarding Claim 2, Norum in view of Khan and Hamid teaches:
The system of claim 1 (see rejection of claim 1 above),
The above cited combination of Norum in view of Khan and Hamid does not explicitly disclose:
wherein the secure element (5) is embedded in a smart card having stored thereon a certificate (7) for establishing the smart card as a trusted device, and the presence of the secure element (5) is detected when the smart card is inserted
However, in an analogous art, Klawe disclose:
wherein the secure element (5) is embedded in a smart card having stored thereon a certificate (7) for establishing the smart card as a trusted device, and the presence of the secure element (5) is detected when the smart card is inserted (Klawe: [0129] In some embodiments, payment object reader 22 also includes an EMV slot 21 that is capable of receiving chip card 14. Chip card 14 may have contacts that engage with corresponding contacts of payment object reader 22 when chip card 14 is inserted into EMV slot 21. Payment object reader 22 provides power to an EMV chip of chip card 14 through these contacts and payment object reader 22 and chip card 14 communicate through a communication path established by the contacts).
A person having ordinary skill in the art, before the effective filing date of the invention, would have found it obvious to modify Norum in view of Khan and Hamid by applying the well-known technique as disclosed by Klawe of establishing communication path by inserting chip card into the EMV slot. The motivation is to determine whether a payment terminal has been tampered with based on a comparison of attestation data received from the payment terminal (Klawe: [Abstract]).
Regarding Claim 3, Norum in view of Khan, Hamid and Klawe teaches:
The system of claim 1 (see rejection of claim 1 above),
The above cited combination of Norum in view of Khan and Hamid does not explicitly disclose:
wherein the secure element (5) is embedded in a USBC e-Token having stored thereon a certificate (7) for establishing the USBC e-Token as a trusted device, and the presence of the secure element (5) is detected when the USBC e-Token is inserted
However, in an analogous art, Klawe disclose:
wherein the secure element (5) is embedded in a USBC e-Token having stored thereon a certificate (7) for establishing the USBC e-Token as a trusted device, and the presence of the secure element (5) is detected when the USBC e-Token is inserted (Hamid: [0039], The digital device 710 may also include one or more of a USB port or device driver 760 for data communications with the token 720 (=e-token)).
A person having ordinary skill in the art, before the effective filing date of the invention, would have found it obvious to modify Norum in view of Khan by applying the well-known technique as disclosed by Hamid of establishing communication by using USB token. The motivation is to provide security for most device users and organizations ensuring data privacy, such as access passwords, biometric readers, hardware security tokens, digital certificates, encryption/decryption, secure socket communications, etc (Hamid: [0002]).
Regarding Claim 4, Norum in view of Khan, Hamid and Klawe teaches:
The system of claim 1 (see rejection of claim 1 above),
The above cited combination of Norum in view of Khan and Hamid does not explicitly disclose:
wherein the secure element (5) is embedded in a Near Field Communication (NFC) chip of a mobile device having stored thereon a certificate (7) for establishing the NFC chip as a trusted device.
However, in an analogous art, Klawe disclose:
wherein the secure element (5) is embedded in a Near Field Communication (NFC) chip of a mobile device having stored thereon a certificate (7) (Klawe: [0059], Payment card may also include a payment object, such as an electronic device configured to initiate contactless payment transactions, e.g., a key fob, a mobile device (such as a mobile device having an NFC tag. [0126], a payment object 5 such as NFC device 12 or chip card 14 may communicate with payment object reader 22 via inductive coupling. This is depicted in FIG. 2 as near field 15, which comprises a wireless carrier signal having a suitable frequency (e.g., 13.56 MHz) emitted from payment object reader 22) for establishing the NFC chip as a trusted device (Klawe: [0035], The reader receives the proof of identity and the identity metric, and compares them against the values provided by the trusted third party. If the measured data reported by the trusted devices are the same as that provided by the trusted third party, the reader can trust the platform. [0038] Once the reader has established trusted operation of the platform and operating environment, a user of the platform is able to exchange data, including sensitive financial data, with other aspects of the platform and the reader),
and the presence of the secure element (5) is detected when the NFC chip is in close proximity to the computer or mobile device (Klawe: [0130] Payment object reader 22 may also include hardware for interfacing with a magnetic strip card (not depicted in FIG. 2). In some embodiments, the hardware may include a slot that guides a customer to swipe or dip the magnetized strip of the magnetic strip card such that a magnetic strip reader can receive payment information from the magnetic strip card. The received payment information is then processed by the payment object reader 22. [0068] The term “swipe” here refers to any manner of triggering (=detecting) a payment object reader to read data from a payment object, such as by dipping into, tapping, hovering, bringing in close contact (=vicinity) or passing the payment object into or through a payment object reader).
A person having ordinary skill in the art, before the effective filing date of the invention, would have found it obvious to modify Norum in view of Khan and Hamid by applying the well-known technique as disclosed by Klawe of triggering (=detecting) a payment object reader to read data from a payment object by dipping into, tapping, hovering, bringing in close contact (=vicinity) or passing the payment object into or through a payment object reader. The motivation is to determine whether a payment terminal has been tampered with based on a comparison of attestation data received from the payment terminal (Klawe: [Abstract]).
Regarding Claim 5, Norum in view of Khan and Hamid and Klawe teaches:
The system of claim 1 (see rejection of claim 1 above),
wherein the computer (3) or mobile device or HSM (10) authenticates the user by way of multi-factor authentication (MFA) (8) (Hamid: [0032] Exemplary embodiments of Cloud HSMs can include using the exemplary Cloud HSMs as PKI tokens 120. Organizations and/or users can then deploy any number of security functions, including, e.g., 2-Factor (MFA) certificate based authentication for workstation, virtual private network (VPN) and single sign-on (SSO) logins, digital signatures for email and document signing, and/or desktop to desktop email encryption).
A person having ordinary skill in the art, before the effective filing date of the invention, would have found it obvious to modify Norum in view of Khan by applying the well-known technique as disclosed by Hamid of detecting USB security device (=secure element) directly plugged into client machine. The motivation is to provide security for most device users and organizations ensuring data privacy, such as access passwords, biometric readers, hardware security tokens, digital certificates, encryption/decryption, secure socket communications, etc (Hamid: [0002]).
Regarding Claim 6, Norum in view of Khan, Hamid and Klawe teaches:
The system of claim 1 (see rejection of claim 1 above),
linking certificates through a chain of trust (13) down to a self-signed certificate (14) on the HSM (Norum: [0092] As part of the request to establish the session, the system may receive a digital certificate that is signed, either directly or indirectly (e.g., verifiable via a chain of trust) by a service certificate authority and a manufacturer certificate authority. [0093] The system may determine whether a digital certificate is valid by determining whether one or more digital signatures found on the certificate is authentic, whether the digital certificate is signed by a required signatory, and/or whether a chain of trust from the certificate to a trusted certificate authority is unbroken. [0064] The CIK may be an asymmetric key pair and the CIC may include the CIK public key and may be self-signed (i.e., digitally signed by the client using the CIK private key) to prove that a particular certificate in the chain originates from a trusted manufacturer source associated with the HSM (10) (Norum: [0049], The manufacturer certificate authority may be a trusted root certificate authority that is trusted to provide a public demonstration of the manufacturer's identity and verify key pairs generated by the manufacturer…[0092], The system may also verify 1114 that the certificate is signed by a valid manufacturer certificate authority)
Norum in view of Khan and Hamid does not explicitly teaches:
wherein the step by the HSM for authenticating the secure element as a trusted device to the HSM by way of the certificate stored thereon comprises.
However, Klawe teaches:
wherein the step by the HSM for authenticating the secure element as a trusted device to the HSM by way of the certificate stored thereon comprises (Klawe: [0038] Once the reader has established trusted operation of the platform and operating environment, a user of the platform is able to exchange data, including sensitive financial data, with other aspects of the platform and the reader…For a system such as reader, the exchange accompanying a valid attestation ticket might involve completion of a secure transaction. In either case, the data exchanged is typically ‘signed’ by one of the trusted devices or platforms. The reader can then have greater confidence that data is being exchanged with a platform whose behavior can be trusted);
A person having ordinary skill in the art, before the effective filing date of the invention, would have found it obvious to modify Norum in view of Khan and Hamid by applying the well-known technique as disclosed by Klawe of triggering (=detecting) a payment object reader to read data from a payment object by dipping into, tapping, hovering, bringing in close contact (=vicinity) or passing the payment object into or through a payment object reader. The motivation is to determine whether a payment terminal has been tampered with based on a comparison of attestation data received from the payment terminal (Klawe: [Abstract]).
Regarding Claim 11, 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 11.
Regarding Claim 12, Norum in view of Khan, Hamid and Klawe teaches:
The method of claim 1 (see rejection of claim 1 above),
detecting insertion of a USBC eToken embedded with the secure element (5) (Hamid: [0039], The digital device 710 may also include one or more of a USB port or device driver 760 for data communications with the token 720, and a smart card reader (or reader/writer) 770 with a smart card reader or reader/writer driver 780 for data communications with the embedded memory device or smart card 730);
wherein the step of detecting the presence of the secure element (5) by the computer or mobile device and the HSM includes one among (Klawe: [0068] The term “swipe” here refers to any manner of triggering (=detecting) a payment object reader to read data from a payment object, such as by dipping into, tapping, hovering, bringing in close contact (=vicinity) or passing the payment object into or through a payment object reader):
detecting insertion of a smart card embedded with the secure element (5) (Klawe: [0129] In some embodiments, payment object reader 22 also includes an EMV slot 21 that is capable of receiving chip card 14. Chip card 14 may have contacts that engage with corresponding contacts of payment object reader 22 when chip card 14 is inserted into EMV slot 21. Payment object reader 22 provides power to an EMV chip of chip card 14 through these contacts and payment object reader 22 and chip card 14 communicate through a communication path established by the contacts);
and detecting a near-field communication chip embedded with the secure element (5) (Klawe: [0130] Payment object reader 22 may also include hardware for interfacing with a magnetic strip card (not depicted in FIG. 2). In some embodiments, the hardware may include a slot that guides a customer to swipe or dip the magnetized strip of the magnetic strip card such that a magnetic strip reader can receive payment information from the magnetic strip card. The received payment information is then processed by the payment object reader 22. [0068] The term “swipe” here refers to any manner of triggering a payment object reader to read data from a payment object, such as by dipping into, tapping, hovering, bringing in close contact (=NFC) or passing the payment object into or through a payment object reader).
wherein the step of authenticating a user of the secure element includes entry of a personal identification number (PIN) or multi-factor authentication (MFA) (8) (Hamid: [0032] Organizations and/or users can then deploy any number of security functions, including, e.g., 2-Factor (=MFA) certificate based authentication for workstation, virtual private network (VPN) and single sign-on (SSO) logins, digital signatures for email and document signing, and/or desktop to desktop email encryption. [0034], Users or organizations can be provided the ability to control which endpoints are allowed to connect to a device. Further, enhancements to password authentication may also be required and/or encouraged, such as notifications to a user's smart phone or other device 110 or platform 410 when an attempt is being made to connect to an associated Cloud HSM 120, or the usage of the smart phone as a second factor of authentication (=MFA)).
A person having ordinary skill in the art, before the effective filing date of the invention, would have found it obvious to modify Norum in view of Khan by applying the well-known technique as disclosed by Hamid of establishing communication by using USB token. The motivation is to provide security for most device users and organizations ensuring data privacy, such as access passwords, biometric readers, hardware security tokens, digital certificates, encryption/decryption, secure socket communications, etc (Hamid: [0002]).
Claim(s) 7-10 and 14-15 are rejected under 35 U.S.C. 103 as being unpatentable over Norum (U. S. PGPub. No. 2020/0059373 A1) (hereinafter “Norum”) in view of Khan (U. S. PGPub. No. 2016/0286391 A1) (hereinafter “Khan”) and Hamid (U. S. PGPub. No. 2013/0179676 A1) (hereinafter “Hamid”), Klawe et al. (U. S. PGPub. No. 2019/0207953 A1) (hereinafter “Klawe”); and further in view of Cronce (U. S. PGPub. No. 2003/149670 A1) (hereinafter “Cronce”)
Regarding Claim 7, Norum in view of Khan, Hamid and Klawe teaches:
The system of claim 1 (see rejection of claim 1 above),
wherein the step by the computer or mobile device for securely storing the set of IP addresses in the secure element comprises (Norum: [0041] The load balancer 116 may include a fleet directory that includes a list of HSMs in the fleet and their respective network addresses (=IP address). The fleet directory may be stored, by the load balancer, in volatile memory (e.g., random access memory (RAM), memory cache, processor registers), persistent storage (e.g., a hard drive, network drive, database, distributed storage network), or a combination thereof) :
generating a customer configuration file that includes the set of IP addresses (Norum: [0081], at least one HSM in the fleet receives 716 the HSM 706 network address and adds information related to the HSM 706 to its configuration data (=generating a configuration file). The configuration data may, for example, include network addresses for some or all HSMs in the fleet);
and storing the signed customer configuration file (11) in the secure element (5) (Norum: [0041] The load balancer 116 may include a fleet directory that includes a list of HSMs in the fleet and their respective network addresses (=IP address). The fleet directory may be stored, by the load balancer, in volatile memory (e.g., random access memory (RAM), memory cache, processor registers), persistent storage (e.g., a hard drive, network drive, database, distributed storage network), or a combination thereof).
The Norum, Khan, Hamid and Klawe does not explicitly disclose:
signing the customer configuration file with a private key (6) associated with a certificate (7) stored on the secure element (5) thereby producing a signed customer configuration file (11).
However, in an analogous art, Cronce teaches:
signing the customer configuration file with a private key (6) associated with a certificate (7) stored on the secure element (5) thereby producing a signed customer configuration file (11) (Cronce: (2003/0149670 A1: [0087], Referring now to FIG. 9, a block diagram of the XML license response document generated by the server 102 is shown. The response document 900 is signed by the publisher's private key, associated with the publisher's certificate 502);
A person having ordinary skill in the art, before the effective filing date of the invention, would have found it obvious to modify Norum, Khan, Hamid and Klawe by applying the well-known technique as disclosed by Cronce of signing XML format document using private key. The motivation is to limiting or eliminating unauthorized use of software, known as software piracy (Clonce: [0003]).
Regarding Claim 8, Norum in view of Khan, Hamid, Klawe and Cronce teaches:
The system of claim 7 (see rejection of claim 7 above),
wherein the step by the HSM (10) for retrieving the set of IP addresses in the secure element (5) comprises (Norum: [0081], In some embodiments, at least one HSM in the fleet receives 716 the HSM 706 network address and adds information related to the HSM 706 to its configuration data. The configuration data may, for example, include network addresses for some or all HSMs in the fleet):
retrieving the signed customer configuration file (11) in the secure element (5) (Norum: [0081], In some embodiments, at least one HSM in the fleet receives 716 the HSM 706 network address and adds information related to the HSM 706 to its configuration data. The configuration data may, for example, include network addresses for some or all HSMs in the fleet);
validating the signature of the signed customer configuration file with a public key (6) associated with the certificate (7) stored on the secure element (5) (Norum: [0093] The system may determine whether a digital certificate is valid by determining whether one or more digital signatures found on the certificate is authentic, whether the digital certificate is signed by a required signatory, and/or whether a chain of trust from the certificate to a trusted certificate authority is unbroken. Additionally, certificates that have expired, been revoked, been blacklisted, or known to be compromised may also be determined to be invalid.);
and retrieving the set of IP addresses from the signed customer configuration file (11) (Norum: [0041] The load balancer 116 may include a fleet directory that includes a list of HSMs in the fleet and their respective network addresses (=IP address). The fleet directory may be stored, by the load balancer, in volatile memory (e.g., random access memory (RAM), memory cache, processor registers), persistent storage (e.g., a hard drive, network drive, database, distributed storage network), or a combination thereof).
Regarding Claim 9, Norum in view of Khan, Hamid and Klawe teaches:
The system of claim 1 (see rejection of claim 1 above),
each of the multiple HSMs is automatically configured with a respective set of the unique IP addresses (Norum: [0040], The load balancer may automatically detect that that the HSM fleet should be scaled up or scaled down without explicit instructions from the client or requiring any special client configuration).
Norum in view of Khan and Hamid does not explicitly disclose below limitations:
wherein the signed customer configuration file (11) in the secure element (5)
However, in an analogous art, Cronce teaches:
wherein the signed customer configuration file (11) in the secure element (5) (Cronce (2003/0149670 A1: [0087], Referring now to FIG. 9, a block diagram of the XML license response document generated by the server 102 is shown. The response document 900 is signed by the publisher's private key, associated with the publisher's certificate 502)
A person having ordinary skill in the art, before the effective filing date of the invention, would have found it obvious to modify Norum, Khan, Hamid and Klawe by applying the well-known technique as disclosed by Cronce of signing XML format document using private key. The motivation is to limiting or eliminating unauthorized use of software, known as software piracy (Clonce: [0003]).
Regarding Claim 10, Norum in view of Khan, Hamid, Klawe and Cronce teaches:
The system of claim 9 (see rejection of claim 9 above),
wherein the step of detecting a presence of the secure element (5) in a vicinity of the HSM (10) occurs automatically (Norum: [0040], The load balancer may automatically detect that that the HSM fleet should be scaled up or scaled down without explicit instructions from the client or requiring any special client configuration…) upon racking, stacking and onboarding multiple HSMs in the onboarding environment (Norum: [0087] FIG. 10 shows an illustrative example of a process 1000 that may be performed to initialize or provision (=onboarding) a virtual HSM. Generally, the process 1000 may be performed by any system that is operable to function as a cryptographic module, such as a physical HSM, virtual HSM, and other cryptographic modules in which the system performing the process 1000 may require assurances that the module is authentic and/or authorized to perform the process (e.g., by establishing a chain of trust from the module to a trusted certificate authority).
Regarding Claim 14, this claim contains identical limitations found within that of claim 9 above albeit directed to a different statutory category (method medium). For this reason the same grounds of rejection are applied to claim 14.
Regarding Claim 15, this claim contains identical limitations found within that of claim 10 above albeit directed to a different statutory category (method medium). For this reason the same grounds of rejection are applied to claim 15.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. Refer to PTO-892, Notice of References Cited for a listing of analogous art.
Krummel et al. (U. S. Pat. No. 12,069,171 B2): According to one exemplary embodiment, a hardware security module is described, having a receiver, which is configured to receive instructions for performing cryptographic operations, and a control device, which is configured to take an instruction load of the hardware security module as a basis for deciding whether one or more instructions should be relocated and, if one or more instructions should be relocated, to determine another hardware security module for relocating the one or more instructions, to authenticate the other hardware security module and to request the execution of the one or more instructions by the other hardware security module.
Siegel et al. (U. S. Pat. No. 7,278,582 B1): Processing circuitry is integrated within a hardware security module (HSM) chip card. The processing circuitry is configured to operate in accordance with a set of program instructions stored in a memory integrated within the HSM chip card. The set of program instructions includes program instructions for implementing a public-key cryptography standard (PKCS). The PKCS includes processes for generating and storing a master key. The master key is to be stored in the memory integrated within the HSM chip card. Also, using the master key stored in the memory of the HSM chip card, the HSM chip card enables direct management control of standard chip cards.
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
/ALEXANDER LAGOR/Supervisory Patent Examiner, Art Unit 2437