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 Objections withdrawn
Applicant’s arguments, see page 1, filed 04/06/2026 with respect to Claim 13 have been fully considered and are persuasive. The claim objection of 01/06/2026 has been withdrawn.
Applicant’s arguments with respect to claim(s) 1-6 and 11-12 have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
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-2, 4, 6, 11 and 16 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 Law et al. (U. S. PGPub. No. 2019/0286805 A1) (hereinafter “Law”) and Khan (U. S. PGPub. No. 2016/0286391 A1) (hereinafter “Khan”); and further in view of and Klawe et al. (U. S. PGPub. No. 2019/0207953 A1) (hereinafter “Klawe”) and Lambert et al. (U. S. PGPub. No. 2023/0104332 A1) (hereinafter “Lambert”) and Jerbi et al. (U. S. PGPub. No. 2003/0067909 A1) (hereinafter “Jerbi”)
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) 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):
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 (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 (=retrieving) 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 (=initializing=configuring) a virtual HSM).
Norum does not explicitly disclose:
a secure element (5) that is embedded in one of a smart card, a USBC e-Token and a Near Field Communication (NFC) chip in a mobile device,
detecting (252) a presence of the secure element (5) in a vicinity of the computer (3) or mobile device;
authenticating (254) the secure element as a trusted device by way of a certificate (7) stored thereon; authenticating (256) a user of the trusted device via the secure element;
establishing (258) a secure communication for programming the secure element responsive to authenticating said secure element and authenticating said user;
receiving (260) a set of Internet Protocol (IP) addresses responsive to user entry on the computer for association with a HSM custom network configuration;
securely storing (262) the set of IP addresses in the secure element (5);
and, a Hardware Server Module (HSM) in an onboarding environment (300), the HSM (10) comprising one or more processors and memory coupled to the one or more processors, 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:
detecting (352) a presence of the secure element (5) in a vicinity of the HSM; authenticating (354) the secure element as a trusted device to the HSM by way of the certificate stored thereon; authenticating (356) a user of the secure element to the HSM;
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 by validating, by the HSM, a first certificate stored on the secure element to establish a secure communication channel between the secure element and the HSM;
authenticating said user by validating, by the HSM, a second certificate stored on the secure element to authenticate the user via the secure element after establishment of the secure communication channel;
and selecting and applying the at least one IP address to the HSM according to network configuration information associated with the HSM and stored in the secure element.
However, an analogous art, Law teach:
A secure element that is embedded in one of a smart card (Law: [0043], Smart card 110 may comprise a chip 112), a USBC e-Token (Law: [0101] The secondary memory may optionally include an internal memory and/or a removable medium (=USB e-token), for example, an insertable flash drive, etc. The removable medium is read from and/or written to in a well-known manner. The removable storage medium may be a non-transitory computer readable medium having stored thereon computer executable code (i.e., software) and/or data. The computer software or data stored on the removable storage medium can be read into the smart card for execution by any processor therein) and a Near Field Communication (NFC) chip in a mobile device (Law: [0046], Such smart cards incorporate various communication protocols, including but not limited to, Europay, MasterCard and Visa (EMV); near-field communication (NFC), Bluetooth (BLE), USB, Wi-Fi, etc. as means of connecting to and communicating with external systems and devices),
establishing (258) a secure communication for programming the secure element responsive to authenticating said secure element and authenticating said user (Law:[0040], In some embodiments, the microcontroller may also be configured to establish a trusted connection and/or verify that the external device is a trusted device based on the encryption parameters, certificates, and/or digital signatures stored in the memory [0117], once the user is authorized, the smart card 110 may be configured to establish a trusted connection with the external device 410, for example, by verifying the external device is a trusted device through the exchange of digitally signed certificates and/or encryption parameters)
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) by applying Law’s method of providing embedded chip in removable storage medium (USB) and NFC chip in mobile device in order to establish trusted connection between tamper resistant smart cards and external devices and to encrypt sensitive data for secure transmission.
Norum in view of Law does not explicitly disclose:
detecting (252) a presence of the secure element (5) in a vicinity of the computer (3) or mobile device;
authenticating (254) the secure element as a trusted device by way of a certificate (7) stored thereon; authenticating (256) a user of the trusted device via the secure element;
establishing (258) a secure communication for programming the secure element responsive to authenticating said secure element and authenticating said user;
receiving (260) a set of Internet Protocol (IP) addresses responsive to user entry on the computer for association with a HSM custom network configuration;
securely storing (262) the set of IP addresses in the secure element (5);
and, a Hardware Server Module (HSM) in an onboarding environment (300), the HSM (10) comprising one or more processors and memory coupled to the one or more processors, 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:
detecting (352) a presence of the secure element (5) in a vicinity of the HSM; authenticating (354) the secure element as a trusted device to the HSM by way of the certificate stored thereon; authenticating (356) a user of the secure element to the HSM;
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 by validating, by the HSM, a first certificate stored on the secure element to establish a secure communication channel between the secure element and the HSM;
authenticating said user by validating, by the HSM, a second certificate stored on the secure element to authenticate the user via the secure element after establishment of the secure communication channel;
and selecting and applying the at least one IP address to the HSM according to network configuration information associated with the HSM and stored in the secure element.
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);
authenticating said secure element by (Khan: [0040] In these ways, electronic device 112 may certify that the secure element in electronic device 110 is valid and that there is a secure chain of certifications going back to the provider of the secure element before providing the content.)
authenticating said user by (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);
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 Law by applying the well-known technique as disclosed by 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 Law and Khan does not explicitly disclose:
receiving (260) a set of Internet Protocol (IP) addresses responsive to responsive to user entry on the computer for association with a HSM custom network configuration;
detecting (352) a presence of the secure element (5) in a vicinity of computer;
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 (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 Law, Khan 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]).
Norum in view of Law, Khan and Klawe does not explicitly disclose:
receiving (260) a set of Internet Protocol (IP) addresses responsive to responsive to user entry on the computer for association with a HSM custom network configuration;
network configuration information associated with the HSM and stored in the secure element.
However, in an analogous art, Lambert teaches:
(Lambert: [0010], validating, with the hardware security module, the first certificate chain by validating each respective subordinate certificate (=first certificate) in the plurality of subordinate certificates. The validation of each respective subordinate certificate comprises receiving, and storing in a memory of the hardware security module, the respective subordinate certificate. The validation of each respective subordinate certificate further comprises storing, in the memory of the hardware security module, a respective signer certificate of a respective entity that issued the respective subordinate certificate, the respective signer certificate having been previously received by the hardware security module. The validation of each respective subordinate certificate further comprises verifying a signature of the respective subordinate certificate using the respective signer certificate.)
(Lambert: [0035] Returning to FIG. 2, the method 200 continues with provisionally validating the certificate chain, with an HSM, by sequentially validating each respective subordinate certificate (=second certificate) (block 220). Particularly, once the certificate chain is identified, the certificate chain can be provisionally validated by at least validating each subordinate certificate in the certificate chain. More particularly, each respective subordinate certificate of the certificate chain is validated by at least verifying the signature of the respective subordinate certificate. If each respective subordinate certificate is determined to be valid, that is to say has a verified signature by from the respective issuing entity, then the certificate chain can be considered provisionally validated).
(Lambert: [0032] In this same manner, the processor 110 and/or the cryptoprocessor 140 iteratively traverses up the certificate tree, identifying each certificate in the certificate chain of the respective certificate until the root certificate is reached. [0056] The processes of block 410, 420, 430, 440, 450, and 460 are repeated in an iterative and sequential manner for each subordinate certificate of the certificate chain, until all subordinate certificates in the certificate chain have been validated. In some embodiments, the root certificate (=third certificate) itself may also be validated by verifying its signature with its public key, in the manner discussed above. Finally, once all of the certificates in the certificate chain are determined to be valid, the certificate chain is considered to be provisionally valid).
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 Law, Khan and Klawe by applying the well-known technique as disclosed by Lambert of validating each certificate in certificate chain. The motivation is to performing cryptographic operations and certificate validations (Lambert: [0007]).
Norum in view of Law, Khan, Klawe and Lambert does not explicitly disclose:
receiving (260) a set of Internet Protocol (IP) addresses responsive to responsive to user entry on the computer for association with a HSM custom network configuration;
However, in an analogous art, Jerbi teaches:
receiving (260) a set of Internet Protocol (IP) addresses responsive to (Jerbi: [0027], the user inserts the smart card SC storing all the IP addresses of his terminals into the notebook T4, where the stored IP addresses are read. The user's IP addresses which are read in are advantageously shown on a display in the form of a menu list (set of IP addresses) from which the user can finally select the IP address of the fixed office computer T4) user entry on the computer for association with a HSM custom network configuration (Jebert: [0017], an IP address can be entered manually by a user in advance using an input device which is connected to the terminal or is integrated in it, and then can be stored on the storage medium automatically or upon instruction by a user. [0025], the user to use one of the terminals which has an input device, such as a keyboard, to enter the IP addresses manually, and then to store these IP addresses on the smart card SC using a writing device provided on the terminal)
and selecting…the at least one IP address (Jerbi: [0027], The user's IP addresses which are read in are advantageously shown on a display in the form of a menu list from which the user can finally select the IP address of the fixed office computer T4…)
and applying the at least one IP address to the HSM according to network configuration information associated with the HSM (Jerbi: [0027], Once the user has selected the IP address of the target terminal, the terminal connected to the smart card SC, in this case the notebook T3, sets up a communications link to the computer T4) and stored in the secure element (Jerbi:. [0029], the user selects the notebook's IP address, which is currently stored on the smart card SC connected to the mobile telephone T1, and sets up a communications link between the mobile telephone T1 and the notebook T3. )
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 Law, Khan, Klawe and Lambert by applying the well-known technique as disclosed by Jerbi of selecting IP address which are associated to the their respective terminal from the list . The motivation is to set up a communications link between two of his/her terminals, the IP address of the further terminal being automatically read out for the communications link without the user needing to remember one of the IP addresses. (Jerbi: [Abstract])
Regarding Claim 2, Norum in view of Law, Khan, Klawe, Lambert and Jerbi teaches:
The system of claim 1 (see rejection of claim 1 above),
The above cited combination of Norum in view of Law, Khan, Klawe, Lambert and Jerbi does not explicitly disclose:
wherein the secure element (5) is embedded in the 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 the 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 Law, Khan, Klawe, Lambert and Jerbi 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 4, Norum in view of Law, Khan, Klawe, Lambert and Jerbi teaches:
The system of claim 1 (see rejection of claim 1 above),
The above cited combination of Norum in view of Law, Khan, Klawe, Lambert and Jerbi does not explicitly disclose:
wherein the secure element (5) is embedded in the Near Field Communication (NFC) chip of the 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 the Near Field Communication (NFC) chip of the 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 (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 Law, Khan, Klawe, Lambert and Jerbi 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 6, Norum in view of Law, Khan, Klawe, Lambert and Jerbi 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 Law, Khan, Klawe, Lambert and Jerbi 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 Law, Khan, Klawe, Lambert and Jerbi 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]).
prove that a particular certificate in the chain originates from a trusted manufacturer source associated with the HSM (10) (Lambert: [0029], A certificate chain is a set of certificates comprising a root certificate and one or more subordinate certificates, in which there is a chain of issuance/signature from the root certificate to a lowest level subordinate certificate. The root certificate is a certificate that identifies a root certificate authority (CA). The root certificate is self-signed by the root certificate authority and establishes a root of trust (=proved that the each certificate in the chain is valid) in a PKI),
wherein the chain of trust is applied to the third certificate stored on the secure element that is (used to authenticate the at least one IP address from the set of IP addresses) (Lambert: [0029] A certificate chain is a set of certificates comprising a root certificate and one or more subordinate certificates, in which there is a chain of issuance/signature from the root certificate to a lowest level subordinate certificate. The root certificate is a certificate that identifies a root certificate authority (CA). The root certificate is self-signed by the root certificate authority and establishes a root of trust in a PKI. In at least one embodiment, the HSM 130 is provisioned with some number of root certificates, which it will trust, in a secure way, typically in an initial secure environment. In contrast, each subordinate certificate has been either (i) issued by the root CA identified by the root certificate or (ii) issued by an intermediate entity identified by another of the subordinate certificates (e.g., a subordinate CA). The certificate chain to be validated is generally part of a larger multi-level certificate tree),
and wherein the third certificate is used within the chain of trust to verify a digital signature (Lambert: [0029] A certificate chain is a set of certificates comprising a root certificate and one or more subordinate certificates, in which there is a chain of issuance/signature from the root certificate to a lowest level subordinate certificate. The root certificate is a certificate that identifies a root certificate authority (CA). The root certificate is self-signed by the root certificate authority and establishes a root of trust in a PKI. In at least one embodiment, the HSM 130 is provisioned with some number of root certificates, which it will trust, in a secure way, typically in an initial secure environment)
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 Law, Khan, Klawe, Lambert and Jerbi by applying the well-known technique as disclosed by Lambert of validating each certificate in certificate chain. The motivation is to performing cryptographic operations and certificate validations (Lambert: [0007]).
Norum in view of Law, Khan, Klawe, Lambert and Jerbi does not explicitly disclose:
and wherein the HSM validates, via the chain of trust, that the at least one IP address is cryptographically bound to the HSM-specific network configuration information stored in the secure element prior to selecting and applying the at least one IP address.
However, Jebert disclose:
and wherein the HSM validates, via the chain of trust, that the at least one IP address is cryptographically bound to the HSM-specific network configuration information stored in the secure element prior to selecting and applying the at least one IP address (Jerbi: [0025] Before it is possible to carry out the inventive method for setting up a communications link, a user first needs to store the IP addresses of the terminals he/she uses on his/her smart card SC. One option for doing this is for the user to use one of the terminals which has an input device, such as a keyboard, to enter the IP addresses manually, and then to store these IP addresses on the smart card SC using a writing device provided on the terminal. Alternatively, it is also conceivable for a respective terminal (=HSM) to have a checking device which checks whether a smart card SC connected to the respective terminal is able to store IP addresses for terminals. For this purpose, it is advantageous if the card is able to indicate its ability to store IP addresses for a terminal. After the checking device acknowledges the ability of the smart card SC to store IP addresses for terminals on it, the checking device uses a writing device to store the IP address of the terminal on the smart card SC. Preferably, following acknowledgement of the storage capability of the smart card SC, the checking device can ask the user, such as via a suitable display, whether or not he/she would like to store the IP address of the terminal on the smart card SC.),
(Jerbi: [0027], The user's IP addresses which are read in are advantageously shown on a display in the form of a menu list from which the user can finally select the IP address of the fixed office computer T4…Once the user has selected the IP address of the target terminal, the terminal connected to the smart card SC, in this case the notebook T3, sets up a communications link to the computer T4...[0034], The storage medium then reads in the IP address of the second terminal, and finally a communications link is set up from the first terminal to the second terminal over the network using the IP address which has been read)
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 Law, Khan, Klawe and Lambert by applying the well-known technique as disclosed by Jerbi of selecting IP address which are associated to the their respective terminal from the list . The motivation is to set up a communications link between two of his/her terminals, the IP address of the further terminal being automatically read out for the communications link without the user needing to remember one of the IP addresses. (Jerbi: [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 13, Norum in view of Law, Khan, Klawe, Lambert, Jerbi teaches:
The system of claim 1 (see rejection of claim 1 above),
This claim contains identical limitations found within that of claim 8 above albeit directed to a different statutory category (non-transitory medium). For this reason the same grounds of rejection are applied to claim 13.
wherein the third certificate is used to verify a digital signature (Lambert: [0056] The processes of block 410, 420, 430, 440, 450, and 460 are repeated in an iterative and sequential manner for each subordinate certificate of the certificate chain, until all subordinate certificates in the certificate chain have been validated. In some embodiments, the root certificate (=third certificate) itself may also be validated by verifying its signature with its public key, in the manner discussed above. Finally, once all of the certificates in the certificate chain are determined to be valid, the certificate chain is considered to be provisionally valid) over the set of IP addresses or over a customer configuration file comprising the set of IP addresses stored in the secure element (Jerbi: [0027], The user's IP addresses which are read in are advantageously shown on a display in the form of a menu list from which the user can finally select the IP address of the fixed office computer T4…Once the user has selected the IP address of the target terminal, the terminal connected to the smart card SC, in this case the notebook T3, sets up a communications link to the computer T4...[0034], The storage medium then reads in the IP address of the second terminal, and finally a communications link is set up from the first terminal to the second terminal over the network using the IP address which has been read)
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 Law, Khan, Klawe and Lambert by applying the well-known technique as disclosed by Jerbi of selecting IP address which are associated to the their respective terminal from the list . The motivation is to set up a communications link between two of his/her terminals, the IP address of the further terminal being automatically read out for the communications link without the user needing to remember one of the IP addresses. (Jerbi: [Abstract])
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.
Regarding Claim 16, this claim contains identical limitations found within that of claim 6 above albeit directed to a different statutory category (method medium). For this reason the same grounds of rejection are applied to claim 16.
Claim(s) 3, 5, 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 Law et al. (U. S. PGPub. No. 2019/0286805 A1) (hereinafter “Law”), Khan (U. S. PGPub. No. 2016/0286391 A1) (hereinafter “Khan”), Klawe et al. (U. S. PGPub. No. 2019/0207953 A1) (hereinafter “Klawe”), Lambert et al. (U. S. PGPub. No. 2023/0104332 A1) (hereinafter “Lambert”) and Jerbi et al. (U. S. PGPub. No. 2003/0067909 A1) (hereinafter “Jerbi”); and further view of Hamid (U. S. PGPub. No. 2013/0179676 A1) (hereinafter “Hamid”),
Regarding Claim 3, Norum in view of Law, Khan, Klawe, Lambert, Jerbi teaches:
The system of claim 1 (see rejection of claim 1 above),
The above cited combination of Norum in view of Law, Khan, Klawe, Lambert, Jerbi does not explicitly disclose:
wherein the secure element (5) is embedded in the 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 the 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 Law, Khan, Klawe, Lambert, Jerbi 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 5, Norum in view of Law, Khan, Klawe, Lambert, Jerbi teaches:
The system of claim 1 (see rejection of claim 1 above),
wherein the computer (3) 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 Law, Khan, Klawe, Lambert, Jerbi 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 12, Norum in view of Law, Khan, Klawe, Lambert, Jerbi 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 Law, Khan, Klawe, Lambert, Jerbi 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 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 Law et al. (U. S. PGPub. No. 2019/0286805 A1) (hereinafter “Law”), Khan (U. S. PGPub. No. 2016/0286391 A1) (hereinafter “Khan”), Klawe et al. (U. S. PGPub. No. 2019/0207953 A1) (hereinafter “Klawe”), Lambert et al. (U. S. PGPub. No. 2023/0104332 A1) (hereinafter “Lambert”) and Jerbi et al. (U. S. PGPub. No. 2003/0067909 A1) (hereinafter “Jerbi”); and further in view of Cronce (U. S. PGPub. No. 2003/149670 A1) (hereinafter “Cronce”)
Regarding Claim 7, Norum in view of Khan, Klawe, Lambert and Jerbi 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).
wherein the third certificate is used to verify a digital signature (Lambert: [0032] In this same manner, the processor 110 and/or the cryptoprocessor 140 iteratively traverses up the certificate tree, identifying each certificate in the certificate chain of the respective certificate until the root certificate is reached. [0056] The processes of block 410, 420, 430, 440, 450, and 460 are repeated in an iterative and sequential manner for each subordinate certificate of the certificate chain, until all subordinate certificates in the certificate chain have been validated. In some embodiments, the root certificate (=third certificate) itself may also be validated by verifying its signature with its public key, in the manner discussed above. Finally, once all of the certificates in the certificate chain are determined to be valid, the certificate chain is considered to be provisionally valid).
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 Law, Khan and Klawe by applying the well-known technique as disclosed by Lambert of validating each certificate in certificate chain. The motivation is to performing cryptographic operations and certificate validations (Lambert: [0007]).
over the set of IP addresses or over a customer configuration file comprising the set of IP addresses stored in the secure element (Jerbi: [0027], The user's IP addresses which are read in are advantageously shown on a display in the form of a menu list from which the user can finally select the IP address of the fixed office computer T4…Once the user has selected the IP address of the target terminal, the terminal connected to the smart card SC, in this case the notebook T3, sets up a communications link to the computer T4...[0034], The storage medium then reads in the IP address of the second terminal, and finally a communications link is set up from the first terminal to the second terminal over the network using the IP address which has been read)
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, Klawe, Lambert and Jerbi by applying the well-known technique as disclosed by Jerbi of selecting IP address which are associated to the their respective terminal from the list . The motivation is to set up a communications link between two of his/her terminals, the IP address of the further terminal being automatically read out for the communications link without the user needing to remember one of the IP addresses. (Jerbi: [Abstract])
The Norum in view of Khan, Klawe, Lambert and Jerbi 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 in view of Khan, Klawe, Lambert and Jerbi 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 (Cronce: [0003]).
Regarding Claim 8, Norum in view of Khan, Klawe, Lambert and Jerbi 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, Klawe, Lambert and Jerbi 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, Klawe, Lambert and Jerbi 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 in view of Khan, Klawe, Lambert and Jerbi 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 (Cronce: [0003]).
Regarding Claim 10, Norum in view of Khan, Klawe, Lambert and Jerbi 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).
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.
SHIPLEY (U. S. PGPub. No. 2014/0248853 A1): The exemplary embodiments described herein relate to systems and methods for identifying and authenticating a mobile platform. One embodiment relates to a method comprising receiving, by a mobile platform, a digital certificate from an integrated circuit card ("ICC") via close-proximity radio communication, verifying the digital certificate with a digital signature stored on the mobile platform, and booting the mobile platform upon verification of the digital certificate of the ICC. A further embodiment relates to a mobile platform, comprising a non-transitory computer readable storage medium storing a digital signature, and a processor receiving a digital certificate from an integrated circuit card ("ICC") via close- proximity radio communication between the ICC and the mobile platform, verifying the digital certificate with the digital signature, booting the mobile platform upon verification of the digital certificate of the ICC.
NITSCHKE (U. S. PGPub. No. 2017/0054566 A1): The exemplary embodiments described herein relate to systems and methods for identifying and authenticating a mobile platform. One embodiment relates to a method comprising receiving, by a mobile platform, a digital certificate from an integrated circuit card ("ICC") via close-proximity radio communication, verifying the digital certificate with a digital signature stored on the mobile platform, and booting the mobile platform upon verification of the digital certificate of the ICC. A further embodiment relates to a mobile platform, comprising a non-transitory computer readable storage medium storing a digital signature, and a processor receiving a digital certificate from an integrated circuit card ("ICC") via close- proximity radio communication between the ICC and the mobile platform, verifying the digital certificate with the digital signature, booting the mobile platform upon verification of the digital certificate of the ICC.
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
Prosecution Insights