DETAILED ACTION
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
This office action is in response to communication filed on October 08, 2025.
Status of claims within the instant application:
Claims 1 – 6 are pending.
Claims 1 – 6 are amended.
Response to Amendment
Applicant’s arguments with respect to claim 1 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
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1 – 6 are rejected under 35 U.S.C. 103 as being unpatentable over US 20200366478 A1 to Mestery et al., (hereinafter, “Mestery”) in view of US 20210281578 A1 to Olson et al., (hereinafter, “Olson”) and US 20170364698 A1 to Goldfarb et al., (hereinafter, “Goldfarb”).
Regarding claim 1, Mestery teaches A security system for a cloud computing platform, the security system comprising: a plurality of security service servers, [Mestery, para. 21 disclose the IKE servers or IKE servers 116a-d are scaled horizontally, meaning there are a plurality of IKE servers or IKE servers 116a-d that may service the connections between a user 106 and an environment 108.] each of the plurality of security service servers having at least one data processor that is configured to provide security services on information, [Mestery, para. 21 disclose the environment may be embodied as a public network, such as the internet, or in a form of one or more private networks. The user 106 communicates with the environment 108 via one of the ESP servers 114a-e using a User Data Protocol (UDP) or another ESP protocol such as protocol 50. The UDP may use a port 4500 but these are provided by way of an example and not by way of a limitation. The user 106 also communicates with one of the IKE servers 116a-d (e.g., servers) to establish a security association. For example, a UDP protocol or another IKE protocol such as protocol 51 may be used. The UDP may use a port five hundred. For example, the user 106 will indicate to the IKE server that I am user X with a password Y. The user 106 may propose to use these encryption algorithms and keys, and negotiate a time for refreshing the keys (e.g., 30 min).] one of the plurality of security service servers being designated in a startup phase of the security system as an active server to execute the security services, [Mestery, para. 26 discloses as illustrated in the IPSec key negotiation process 200, traffic 202, 204, 206 is initially sent between the initiator server A and the responder server C. According to the example depicted in FIG. 2, it is assumed that the initiator server A is the IKE server and it is further assumed that a new SA (or child SA, used interchangeably) has been generated. In operation 208, a rekeying is initiated, and messages 210-220 are exchanged between the initiator server A and the responder server C] and one or more other of the plurality of security service servers being designated as standby servers; [Mestery, para. 28 disclose the server C responder is the endpoint device (user 106 in FIG. 1). Either one of the IKE servers or server C responder or a responder server (the endpoint device) may initiate the IKE rekeying. In the event the rekeying is initiated by a server C responder, due to hashing, the rekeying request initiated by the server C responder may be received by any of the IKE servers such as IKE server B in FIG. 3], but Mestery does not teach one or more performance standby servers designated from the standby servers by receiving an instruction in response to connecting to the active server, wherein the instruction causes the performance standby servers being configured to execute the security services only in response to read-only requests that do not modify the information, each designated one or more performance standby servers being further configured to forward to the active server any requests that modify the information, each of the one or more performance standby servers having an embedded cache storing one or more cache objects related to the security services provided by the one or more performance standby servers, the one or more cache objects including one or more of encryption keys, transport layer security certificates, security tokens and leases, at least some of the cache objects being invalidated by a write-ahead log (WAL) stream received by the one or more performance standby servers from the active server, wherein the one or more performance standby servers are tagged in a service registry of the cloud computing platform..
However, Olson does teach one or more performance standby servers designated from the standby servers by receiving an instruction in response to connecting to the active server, [Olson, para. 4 discloses one or more of a network interface configured to receive a gossip message originated from a domain anchor peer in a first security domain, and a processor configured to one or more of verify that block content within the gossip message does not violate a cross-domain security policy, and in response to verification of the block content, update an endpoint of the gossip message with an address of a domain anchor peer in a second security domain, wherein the processor may be further configured to control the network interface to transmit the updated gossip message to the domain anchor peer in the second security domain.] wherein the instruction causes the performance standby servers being configured to execute the security services only in response to read-only requests that do not modify the information, [Olson, para. 45 discloses the multi-domain relay may also relay gossip messages (including state information of the blockchain ledger) from one security domain to another security domain without revealing any sensitive cross-membership information (e.g., channel information, peer IDs, peer addresses, etc.) between the two domains. Para. 32 discloses The decentralized database includes an append-only immutable data structure resembling a distributed ledger capable of maintaining records between mutually untrusted parties. The untrusted parties are referred to herein as peers or peer nodes. Each peer maintains a copy of the database records and no single peer can modify the database records without a consensus being reached among the distributed peers.] each designated one or more performance standby servers being further configured to forward to the active server any requests that modify the information, [Olson, para. 45 discloses the example embodiments modify the gossip protocol of a blockchain network by removing channel membership information and peer identification information and enabling a multi-domain relay to insert endpoint information into a gossip message. In the example above, the multi-domain relay may receive a gossip message from the high side domain anchor peer with state information of the blockchain ledger in the high side. Here, the multi-domain relay may insert an endpoint of a low side domain anchor peer into the gossip message while removing or ensuring that any membership information of the high side domain is out of the gossip message. The multi-domain may then route the modified gossip message to the low side domain anchor peer. The process may be repeated in reverse as well. Thus, both sides (high and low) may share ledger state information via the multi-domain relay without revealing channel membership information.] each of the one or more performance standby servers having an embedded cache storing one or more cache objects related to the security services provided by the one or more performance standby servers, [Olson, para. 53 discloses the block creator 120 and domain controllers 121 and 122 together prevent any direct domain-to-domain communication and enforce cross-domain endorsement and content policies (i.e., ensuring that the storage event has been properly endorsed and contains no unauthorized information such as the original proposed transaction). The block creator 120 may ensure that prior to inclusion in a block, every transaction is inspected and validated. The block creator 120 may include domain security policies defined and approved by the operator(s) of the guard. The block creator 120 may only connect to the domain controllers 121 and 122, thereby preventing connections with peer nodes and other computing systems in the respective domains 110 and 130.] at least some of the cache objects being invalidated by a write-ahead log (WAL) stream received by the one or more performance standby servers from the active server, [Olson, para. 55 discloses The domain controllers 121 and 122 receive, validate, and forward transactions from (untrusted) clients to the trusted block creator 120, performing the same validation as a committing peer and applying any domain specific filtering policies. In some embodiments, the policies may be defined and approved by the providers/operators of the guard. Cross-domain compliant smart contracts executed by peer nodes during the endorsement phase generate the cross-domain compliant read/write sets. The function of the domain controllers is not to duplicate the endorsement process by re-running these smart contracts. Instead, their purpose is to prevent unendorsed, improperly endorsed, or other types of invalid client-submitted transactions from ever reaching the block-creating mechanism 120.] wherein the one or more performance standby servers are tagged in a service registry of the cloud computing platform. [Olson, para. 118 discloses Metadata fields may include signature on block creation, a reference to a last configuration block, a transaction filter identifying valid and invalid transactions within the block, last offset persisted of an ordering service that ordered the block, and the like. The signature, the last configuration block, and the orderer metadata may be added by the ordering service 710. Meanwhile, a committer of the block (such as blockchain node 712) may add validity/invalidity information based on an endorsement policy, verification of read/write sets, and the like. The transaction filter may include a byte array of a size equal to the number of transactions that are included in the block data 750 and a validation code identifying whether a transaction was valid/invalid.]
Therefore, it would have been obvious to one of ordinary skill within the art before the effective filing date to combine Olson’s system with Mestery’s system, with a motivation to ensures that only data conforming to the security and business policies of each security domain passes across a domain boundary via the gossip messages. In general, cross-domain policies prevent inappropriately classified information from passing from the higher-to-lower security network domains (referred to as spillage) and to prevent malicious data from flowing low-to-high (e.g., viruses, etc.) [Olson, para. 47]
However, Mestery in view of Olson does not teach the one or more cache objects including one or more of encryption keys, transport layer security certificates, security tokens and leases, but Goldfarb does teach the one or more cache objects including one or more of encryption keys, transport layer security certificates, security tokens and leases, [Goldfarb, para. 31 discloses the lower-trust database 14 is one of the various types of datastores described above. In some cases, the lower-trust database 14 is a relational database, having a plurality of tables, each with a set of columns corresponding to different fields, or types of values, stored in rows, or records (i.e., a row in some implementations) in the table, in some cases, each record, corresponding to a row may be a tuple with a primary key that is unique within that respective table, one or more foreign keys that are primary keys in other tables, and one or more other values corresponding to different columns that specify different fields in the tuple. Or in some cases, the database may be a column-oriented database in which records are stored in columns, with different rows corresponding to different fields. In some embodiments, the lower-trust database 14 may be a relational database configured to be accessed with structured query language (SQL) commands, such as commands to select records satisfying criteria specified in the command, commands to join records from multiple tables, or commands to write values to records in these tables.]
Therefore, it would have been obvious to one of ordinary skill within the art before the effective filing date to combine Goldfarb’s system with modified Mestery’s system, with a motivation that with this tight coupling, if the data is altered at all, the entire hash for the tree (as is distinct from a hash of a file stored in the database) is thrown off immediately and ultimately the chain will be broken and detected as such during validation operations [Goldfarb, para. 78]
Regarding claim 2, modified Mestery teaches the system in accordance with claim 1, but modified Mestery does not teach wherein the WAL stream is started based on a Merkle root read from the active server and unsealed in each of the one or more performance standby servers, the Merkle root connecting the active server with each of the one or more performance standby servers.
However, Goldfarb does teach wherein the WAL stream is started based on a Merkle root read from the active server and unsealed in each of the one or more performance standby servers, [Goldfarb, para. 116 discloses the read command may be received after the write command, e.g., substantially later, for instance more than an hour, day, or week later. In some cases, the read command may be received after multiple write commands for the same document in which different versions are written to different servers in different blocks, and in some cases to different directed acyclic graphs like those described above with reference to FIG. 3. In some embodiments, the read command may reference an identifier of a document that indicates a most current version of the document is to be retrieved, or in some cases the read command may reference a particular version of the document. In some cases, receiving the read command may cause the security driver 30 to access the lower-trust database 14 or other lower-trust data store and retrieve a pointer to a server or sequence of servers in which the specified document is stored.] the Merkle root connecting the active server with each of the one or more performance standby servers. [Goldfarb, para. 97 discloses an individual server may store multiple documents as attributes of that server. In some embodiments, blocks have an integer index, a block capacity, a cryptographic hash value based on all of the servers in the block (like a Merkle root), the servers within the block, and a cryptographic hash based on content of a previous block (e.g., based on all values in the block, based on a Merkle root of that block, or the like).]
Therefore, it would have been obvious to one of ordinary skill within the art before the effective filing date to combine Goldfarb’s system with modified Mestery’s system, with a motivation that with this tight coupling, if the data is altered at all, the entire hash for the tree (as is distinct from a hash of a file stored in the database) is thrown off immediately and ultimately the chain will be broken and detected as such during validation operations [Goldfarb, para. 78]
Regarding claim 3, modified Mestery teaches the system in accordance with claim 1, but modified Mestery does not teach wherein the security services include indexing the secrets and/or data by the active server using a Merkle tree.
However, Goldfarb does teach wherein the security services include indexing the secrets and/or data by the active server using a Merkle tree. [Goldfarb, para. 78 discloses some embodiments of Docuchain store the data directly in Merkle Trees, though embodiments are not limited to data storage in Merkle Trees, which is not to suggest that other descriptions are limiting. That is, when data is written to the database or read from the database, that data is written into specific fields of the elements (e.g., attributes of server content of servers) of the Merkle Tree or read from specific fields of the elements of the Merkle Tree (rather than just a hash digest of the data residing in the Merkle Tree with the entire data residing in an external datastore). With this tight coupling, if the data is altered at all, the entire hash for the tree (as is distinct from a hash of a file stored in the database) is thrown off immediately and ultimately the chain will be broken and detected as such during validation operations.]
Therefore, it would have been obvious to one of ordinary skill within the art before the effective filing date to combine Goldfarb’s system with modified Mestery’s system, with a motivation that with this tight coupling, if the data is altered at all, the entire hash for the tree (as is distinct from a hash of a file stored in the database) is thrown off immediately and ultimately the chain will be broken and detected as such during validation operations [Goldfarb, para. 78]
As per claim 4, modified Mestery teaches the system in accordance with claim 1, wherein the plurality of security service servers are designated to run in either server mode as a server node or client mode as a client node. [Mestery, para. 21 discloses the IKE servers or IKE servers 116a-d are scaled horizontally, meaning there are a plurality of IKE servers or IKE servers 116a-d that may service the connections between a user 106 and an environment 108. The user 106 is an endpoint or a client device such as a computer. The environment may be embodied as a public network, such as the internet, or in a form of one or more private networks. The user 106 communicates with the environment 108 via one of the ESP servers 114a-e using a User Data Protocol (UDP) or another ESP protocol such as protocol 50.]
As per claim 5, modified Mestery teaches the system in accordance with claim 4, wherein the plurality of security service servers are allocated to one of a plurality of availability zones of the cloud computing platform. [Mestery, para. 19 discloses That is, example embodiments provide for rekey events for both IKE and ESP sessions to be handled by any IKE server in, for example, a cloud-native VPN installation, in which IKE servers have been horizontally scaled (i.e., in which there are two or more IKE servers configured to handle any IKE or ESP session in the environment). Accordingly, example embodiments provide for dynamic rekeying of IKE and ESP sessions in which the rekey processing is split across servers in the middle of the rekey event itself, allowing for more dynamic rekey events and cloud-native IPSec in terms of the rekeying of session tunnels.]
As per claim 6, modified Mestery teaches the system in accordance with claim 5, wherein each availability zone of the plurality of availability zones includes one or more server nodes and one or more client nodes. [Mestery, para. 21 discloses the IKE servers or IKE servers 116a-d are scaled horizontally, meaning there are a plurality of IKE servers or IKE servers 116a-d that may service the connections between a user 106 and an environment 108. The user 106 is an endpoint or a client device such as a computer. The environment may be embodied as a public network, such as the internet, or in a form of one or more private networks. The user 106 communicates with the environment 108 via one of the ESP servers 114a-e using a User Data Protocol (UDP) or another ESP protocol such as protocol 50.]
Conclusion
Pertinent prior art made of record however not relied upon:
US 20210328789 A1 to Hosur et al.
“Disclosed techniques relate to caching tenant encryption keys for a multi-tenant database. In some embodiments, a computing system encrypts data for a database in a multi-tenant database system using encryption keys assigned to respective tenants that are using the database. The computing system may store the encryption keys in a cache and, in response to a key rotation request for a first tenant, invalidate an entry in the cache for the first encryption key of the first tenant. The computing system may block writes for the first tenant until a new key is cached (e.g., based on retrieval from a key management system). In various embodiments, disclosed techniques may reduce encryption latency.”
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Phuc Pham whose telephone number is (571)272-8893. The examiner can normally be reached Monday - Thursday 7:30 AM - 4:30 PM; Friday 8:00 AM - 12:00 PM.
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, Linglan Edwards can be reached on (571) 270-5440. 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.
/P.P./Patent Examiner, Art Unit 2408
/LINGLAN EDWARDS/Supervisory Patent Examiner, Art Unit 2408