Acknowledgements
This communication is in response to applicant’s response filed on 02/12/2026.
Claims 1-2, 10, 17, and 21-22 have been amended. Claims 3-4, 6-9, and 14 have been cancelled. Claims 23-26 have been added.
Claims 1-2, 5, 10-13, 15-26 are pending and have been examined.
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 .
Response to Arguments
Regarding applicant’s arguments:
Applicant’s arguments, see pg. 9, filed 02/12/2026, with respect to the interpretation of claim 21 under Claim Interpretation - 35 USC § 112(f) that the claim does not invoke 112(f) because the word “means” has been deleted are persuasive. The Claim Interpretation - 35 USC § 112(f) of claim 21 has been withdrawn.
Applicant’s arguments, see pg. 9, filed 02/12/2026, with respect to the rejection of claim 22 under Claim Rejections - 35 USC § 101 that the rejection no longer applies because the claim has been amended to include “non-transitory” are persuasive. The Claim Rejections - 35 USC § 101 of claim 22 has been withdrawn.
Applicant’s arguments, see pg. 10, filed 02/12/2026, with respect to the rejection(s) of claims 1 and 21-22 under Claim Rejections - 35 USC § 102 that Pontecorvi (EP 3575953A1) does not teach the amended limitations of claims 1 and 21-22 have been considered, and the rejection has been withdrawn. However, upon further consideration, a new ground(s) of rejection is made in view of Thom (US 20180077184).
Priority
Applicant's claim for the benefit of PCT Application No. PCT/EP2023/053053 filed on 02/08/2023 is acknowledged. Applicant's claim for the benefit of United Kingdom Application No. GB2202950.8 filed on 03/03/2022 is acknowledged.
Claim Rejections - 35 USC § 102(a)(1)
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 (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
Claims 1-2, 5, 10-11, 15-18, and 21-26 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Thom (US 20180077184).
Regarding Claims 1, 21, and 22, Thom teaches (a) loading a software agent on each of a plurality of peer-to-peer computing systems, the software agents making up a network of distributed software agents (Paragraphs 0022 and 0026 teach an example system for distributed logging of security events includes a computer device in communication over a wired and/or wireless network with one or more other trusted computer devices, thereby forming a trusted network; trusted computer devices may include any device that computer device may communicate with over network that computer device has been instructed or has verified as trustworthy; trusted computer devices may operate on the same network as computer device or may operate on a different network than computer device; trusted computer devices may include, but are not limited to, other devices that an owner of computer device has identified as being trustworthy, devices that have proved their trustworthiness based on performance in maintaining and validating security event logs, devices associated with trusted user as identified by a user of computer device, or any devices that may be deemed trustworthy in any other manner; examples of types of trusted computer devices may include, but are not limited to, laptop, desktop, or tablet computers, gaming devices, home management systems or controllers, multimedia devices, washer/dryers, thermostats, ovens, televisions, refrigerators, dish washers, microwaves, alarms, routers, coffee makers, cameras, cellular telephones, speakers, music devices, and/or any other type of Internet of Things (IoT) device; each security log manager operates in this manner, e.g., publishing local security events and receiving and storing security events from other devices in the trusted network, for a certain time interval known to all security log managers); (b) using the network of distributed software agents to manage the decentralized repository of stored digital units of information (Paragraph 0023 teaches the computer device, and at least one or more of the trusted computer devices, includes a security log manager configured to manage tracking of security events that occur on the computer device and on other respective trusted computer devices in the trusted network; for instance, each security log manager includes one or more device logs having one or more security events associated with a given time interval; as such, computer device and one or more other trusted computer devices having logs for tracking security events within the trusted network define the system for distributed logging of security events; as described herein, security events may include, but are not limited to, opening a port, creating a buffer, event ordering, event repetition, event duplication, event sequence recording and playback, or any other event that a third party may have a benefit if the event has been erased or manipulated; events may include, but are not limited to, starting or stopping services, log-on, configuration changes, file system Access Control List (ACL) changes (e.g., lowering ACLs), file deletion, and renaming); wherein at least one of (i) software agent code for at least one of the software agents, and (ii) a cryptographic digest of such software agent code, is stored in at least one block in the decentralised repository (Paragraphs 0024-0025, 0027, 0029, 0044-0045 teach with respect to local security events, each security log manager may record in a respective device log one or more security events occurring on a respective local device, e.g., security events on computer device, are collected in respective device log and trusted security events on trusted computer device are collected in respective device log; as such, a respective device log on computer device may include a record of security events occurring on computer device, and each respective device log on each respective trusted computer device may include a record of trusted security events occurring on each respective trusted computer device; in addition, each security log manager may transmit the local security events to the other computer devices on the trusted network, which may be referred to as publishing the security events; for example, security log manager on computer device may transmit security events to one or more trusted computer devices in communication with computer device over network; in this case, one or more trusted computer devices that are capable of recording security events in a respective device log, including devices having sufficient memory such as but not limited to routers, personal computers, and any other devices with sufficient storage capacity) may record the published security events; additionally, each security log manager stores a record representative of prior, confirmed security events that have occurred in the trusted network in one or more previous time intervals; in an example, such record may be in the form of a cryptographic historical digest, e.g., a hash, based on previously logged security events published by devices in the trusted network; historical digest has a value that is confirmed or agreed upon, via consensus among two or more devices in the trusted network; if hash generated by calculator component does satisfy hash value threshold, and if a published nonce that corresponds to hash having a value that satisfies hash value threshold has not been received from another device in trusted network, then calculator component and/or verification component initiate the publishing of nonce to the other devices in trusted network (or at least to devices having security log managers); upon receiving verification from one or more other devices in trusted network (e.g., by inputting the published nonce into the hash function with the other known inputs), and/or upon verifying a nonce received from another device, the devices in the trusted network agree upon the value of hash, which is then stored by security log manager as a new digest associated with the security events logged for the respective time interval. Thus, a plurality of devices in trusted network may have logs of historical security events published by devices in the network, and such distributed logs are built upon one another and cryptographically protected, thereby vastly increasing the difficulty for any hacker attempting to alter a security event on a device in the trusted network; the method may include recording the new security events on a device log; in an aspect, security log manager may record the received new security events and/or trusted security events in device log (FIG. 1), which may be stored in memory; in addition, the method may optionally include transmitting the one or more new security events to other devices communicating on a trusted network; for example, when the security event is a local security event, such as security event on computer device, security log manager may transmit the received new security events to one or more trusted computer device in communication with computer device; in an aspect, the trusted computer devices in the trusted network are devices that are capable of recording logs (e.g., routers, computers, or other devices with sufficient storage capacity); as such, in this example, one or more trusted computer devices may record the transmitted new security events from computer device on their respective device log); the management at step (b) includes: the software agents monitoring the decentralized repository for units which have false values for cryptographic digests (Paragraphs 0032 and 0056-0058 teach the computer device may include a security monitor to verify the integrity of computer device and/or other trusted computer devices operating in the trusted network; security monitor may be configured to occasionally review and compare device logs, historical digests, and/or new digests among different devices on trusted network to verify the information in a respective device log, historical digest, and/or new digest is correct; when the review of a respective device log, historical digest, and/or new digest identifies abnormalities in the information, e.g., information in the respective device log, historical digest, and/or new digest is incorrect and/or missing, security monitor may identify one or more devices (e.g., computer device and/or one or more trusted computer devices) that may have provided incorrect information for the respective device log, historical digest, and/or new digest; the method may include accessing a set of security information; a set of security information may include, but is not limited to, device log, historical digest, and/or new digest; for example, security monitor may occasionally review the information in device log, historical digest, and/or new digest to verify whether the information is correct; the method may also include comparing the security information with a trusted network security log; for example, security monitor may compare the information in device log, historical digest, and/or new digest with information stored in trusted network security log record; as such, security monitor may be able to compare the security information among different devices in the trusted network; the method may include verifying whether the security information is accurate; for example, when security monitor compares the information in device log, historical digest, and/or new digest with information stored in trusted network security log record, security monitor may identify abnormalities in the security information; abnormalities in the security information may include, but are not limited to, incorrect data or missing data); and once a unit which has a false value for a cryptographic digest is identified, preventing any new units from attaching to the identified unit (Paragraph 0059 teaches when the review of the security information indicates that the data is incorrect (e.g., one or more abnormalities are detected in the data), the method may include identifying one or more devices with incorrect security information; for example, when security monitor identifies abnormalities in the information, e.g., information in the respective device log, historical digest, and/or new digest is incorrect and/or missing, security monitor may identify one or more devices (e.g., computer device and/or one or more trusted computer devices) that may have provided incorrect information for the respective device log, historical digest, and/or new digest; the method may include removing the identified devices from a trusted network; upon an error being detected by security monitor, one or more devices (e.g., computer device and/or one or more trusted computer devices) identified may be removed from the trusted network until the reputation of the device may be established as trustworthy again).
Regarding Claim 1, Thom teaches a method of managing a decentralised repository of stored digital units of information, the decentralised repository comprised of a plurality of inter-acting peer-to-peer computing systems (Paragraph 0056 teaches Referring now to FIG. 4, is an example method for performing a security review that may be executed by operating system on computer device, for example, to verify the integrity of security information).
Regarding Claim 21, Thom teaches a system comprising a plurality of computers for managing a decentralized repository of stored digital units of information, the decentralized repository comprised of a plurality of inter-acting peer-to-peer computing systems, the plurality of computers being configured to work together so as to be configured to perform operations (Paragraph 0022 teaches computer device and/or each trusted computer device in accordance with the present disclosure may include an operating system executed by processor and/or memory of computer device; memory may be configured for storing data and/or computer-executable instructions defining and/or associated with operating system, and processor may execute operating system).
Regarding Claim 22, Thom teaches a non-transitory computer-readable storage medium storing a computer program comprising instructions for carrying out all the steps of the method according to claim 1, when said computer program is executed on a computer system (Paragraph 0073 teaches the steps and/or actions of a method or algorithm described in connection with the aspects disclosed herein may be embodied directly in hardware, in a software module executed by a processor, or in a combination of the two; a software module may reside in RAM memory, flash memory, ROM memory, EPROM memory, EEPROM memory, registers, a hard disk, a removable disk, a CD-ROM, or any other form of storage medium known in the art; an exemplary storage medium may be coupled to the processor, such that the processor can read information from, and write information to, the storage medium; additionally, in some aspects, the steps and/or actions of a method or algorithm may reside as one or any combination or set of codes and/or instructions on a machine readable medium and/or computer readable medium, which may be incorporated into a computer program product).
Regarding Claims 2 and 23, Thom teaches all the limitations of claims 1 and 21 above; and Thom further teaches wherein the management at step (b) includes an operation carried out such that when a new unit of information is being added to the decentralized repository, at least one of the software agents running on at least one peer-to-peer computing system in the selected subset, checks cryptographic information regarding a linking of the new unit to one or more existing units of information, by performing cryptographic processing by the at least one peer-to-peer computing system in a selected subset, to verify the linking and wherein when the check results in a failure to verify the linking, rejecting the addition of the new unit, or sending a validation request to a sender of the new unit requesting additional information regarding the new unit's authenticity (Paragraphs 0052-0055 teach the method may include determining whether the hash value is below a threshold; for example, calculator component may communicate the value of hash to verification component, which determines whether hash has a value less than hash value threshold; if hash has a value equal to, or above, threshold, the method may proceed to determine whether another device on trusted network has published a nonce that corresponds to a hash having a value that satisfies hash value threshold; if the hash value does satisfy the hash value threshold, the method may include transmitting the nonce to other devices in the trusted network; for example, calculator component and/or verification component may initiate the publishing of nonce to the other devices in trusted network (or at least to devices having security log managers); the method may include determining whether one or more other devices in the trusted network have confirmed that the hash value is below a threshold; for example, security log manager may receive a verification from one or more other devices in trusted network (e.g., by inputting the published nonce into the hash function with the other known inputs) that hash value is below a threshold; when the hash value is not confirmed by another device in the trusted network, method may proceed to and the process may repeat until a hash value is accepted and/or verified by other devices in the trusted network; when other devices in the trusted network agree upon the value of hash as satisfying the threshold, the method may include storing a new security event digest based on the hash; the hash may include, for example, the hash value calculated by calculator component or a different hash based on a published nonce received from trusted computer device; for example, security log manager may store a new digest associated with the security events and/or logged for the respective time interval; thus, a plurality of devices in trusted network may have logs of historical security events published by devices in the network, and such distributed logs are built upon one another and cryptographically protected, thereby vastly increasing the difficulty for any hacker attempting to alter a security event on a device in the trusted network).
Regarding Claims 5 and 24, Thom teaches all the limitations of claims 1 and 21 above; and Thom further teaches wherein the management at step (b) includes enforcing logic such that any new unit being added to the decentralised repository requires a predetermined number of agents to collectively co-sign the new unit before it can be added to the decentralized repository (Paragraphs 0054-0055 teach the method may include determining whether one or more other devices in the trusted network have confirmed that the hash value is below a threshold; for example, security log manager may receive a verification from one or more other devices in trusted network that hash value is below a threshold; when the hash value is not confirmed by another device in the trusted network, method may proceed and the process may repeat until a hash value is accepted and/or verified by other devices in the trusted network; when other devices in the trusted network agree upon the value of hash as satisfying the threshold, the method may include storing a new security event digest based on the hash).
Regarding Claim 10, Thom teaches all the limitations of claim 1 above; and Thom further teaches wherein one agent uses the software agent code stored in the at least one unit to verify a state of the agent whose software agent code is stored in the at least one unit, and to determine if such software agent code meets a collective set of criteria (Paragraph 0058 teaches the method may include verifying whether the security information is accurate; for example, when security monitor compares the information in device log, historical digest, and/or new digest with information stored in trusted network security log record, security monitor may identify abnormalities in the security information; abnormalities in the security information may include, but are not limited to, incorrect data or missing data; when the review of the security information indicates that the data is correct (e.g., no abnormalities are detected in the data), the method may proceed and the process may repeat).
Regarding Claim 11, Thom teaches all the limitations of claim 10 above; and Thom further teaches wherein if a selected set of criteria is not met, then any units which have been signed by that agent are rejected (Paragraphs 0059-0061 teach when the review of the security information indicates that the data is incorrect (e.g., one or more abnormalities are detected in the data), the method may include identifying one or more devices with incorrect security information; may include removing the identified devices from a trusted network; the method may also include generating a security notification; for example, security monitor may generate a notification that indicates a security issue may be present in the trusted network; notification may include, for example, a type of error detected and a device identifier for the error and may be transmitted to a user of one or more devices in trusted network (e.g., an owner of computer device and/or one or more trusted computer devices), notifying the one or more users of the potential error).
Regarding Claim 15, Thom teaches all the limitations of claim 1 above; and Thom further teaches wherein the decentralised repository is arranged so that when a new unit is being added, a determination is made by at least one of the inter-acting peer-to-peer computing systems regarding a specific quantity of existing units stored in the decentralised repository, each of which the new unit is to be cryptographically linked to (Paragraph 0052-0053 teach the method may include determining whether the hash value is below a threshold; for example, calculator component may communicate the value of hash to verification component, which determines whether hash has a value less than hash value threshold; if hash has a value equal to, or above, threshold, method may proceed to determine whether another device on trusted network has published a nonce that corresponds to a hash having a value that satisfies hash value threshold; if the hash value does satisfy the hash value threshold, the method may include transmitting the nonce to other devices in the trusted network; for example, calculator component and/or verification component may initiate the publishing of nonce to the other devices in trusted network (or at least to devices having security log managers)).
Regarding Claim 16, Thom teaches all the limitations of claim 15 above; and Thom further teaches wherein the decentralized repository is further arranged so that when a new unit is being added, a determination is made by at least one of the inter-acting peer-to-peer computing systems regarding a specific quantity of peer computing systems each of which stores a plurality of existing units, where the specific quantity of peer computing systems is to be used to access the specific quantity of existing units (Paragraphs 0054-0055 teach the method may include determining whether one or more other devices in the trusted network have confirmed that the hash value is below a threshold; for example, security log manager may receive a verification from one or more other devices in trusted network that hash value is below a threshold; when the hash value is not confirmed by another device in the trusted network, the method may proceed and the process may repeat until a hash value is accepted and/or verified by other devices in the trusted network; when other devices in the trusted network agree upon the value of hash as satisfying the threshold, the method may include storing a new security event digest based on the hash; the hash may include, for example, the hash value calculated by calculator component or a different hash based on a published nonce received from trusted computer device; for example, security log manager may store a new digest associated with the security events and/or logged for the respective time interval).
Regarding Claim 17, Thom teaches all the limitations of claim 16 above; and Thom further teaches wherein the decentralised repository is further arranged so that when a new unit is being added, a selection is made of specific ones of all of the existing units up to a received specific quantity of stored existing units, where the selection has been made from existing units stored by specific ones of the peer computing systems up to a received specific quantity of peer computing systems (Paragraph 0055 teaches when other devices in the trusted network agree upon the value of hash as satisfying the threshold, the method may include storing a new security event digest based on the hash; the hash may include, for example, the hash value calculated by calculator component or a different hash based on a published nonce received from trusted computer device; for example, security log manager may store a new digest associated with the security events and/or logged for the respective time interval; thus, a plurality of devices in trusted network may have logs of historical security events published by devices in the network, and such distributed logs are built upon one another and cryptographically protected, thereby vastly increasing the difficulty for any hacker attempting to alter a security event on a device in the trusted network).
Regarding Claim 18, Thom teaches all the limitations of claim 17 above; and Thom further teaches wherein the decentralised repository is further arranged so that when a new unit is being added, a cryptographic processing operation is performed by taking as inputs to such cryptographic processing, the selected specific existing units and the new unit, and obtaining a result of such cryptographic processing, adding the result into the new unit; and distributing the new unit to a plurality of peer computing systems, thereby adding the new unit to the decentralized repository (Paragraphs 0053-0055 teach if the hash value does satisfy the hash value threshold, the method may include transmitting the nonce to other devices in the trusted network; then determining whether one or more other devices in the trusted network have confirmed that the hash value is below a threshold; for example, security log manager may receive a verification from one or more other devices in trusted network that hash value is below a threshold; when other devices in the trusted network agree upon the value of hash as satisfying the threshold, the method may include storing a new security event digest based on the hash; the hash may include, for example, the hash value calculated by calculator component or a different hash based on a published nonce received from trusted computer device; for example, security log manager may store a new digest associated with the security events and/or logged for the respective time interval; thus, a plurality of devices in trusted network may have logs of historical security events published by devices in the network, and such distributed logs are built upon one another and cryptographically protected, thereby vastly increasing the difficulty for any hacker attempting to alter a security event on a device in the trusted network).
Regarding Claims 25 and 26, Thom teaches all the limitations of claims 21 and 1 above; and Thom further teaches once the unit having the false value for the cryptographic digest is identified, putting the identified unit into a quarantine so that no new units can connect to the identified unit (Paragraphs 0032 and 0060 teach upon an error being detected by security monitor, one or more devices (e.g., computer device and/or one or more trusted computer devices) identified may be removed from the trusted network until the reputation of the device may be established as trustworthy again; the method may include removing the identified devices from a trusted network; upon an error being detected by security monitor, one or more devices (e.g., computer device and/or one or more trusted computer devices) identified may be removed from the trusted network until the reputation of the device may be established as trustworthy again).
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 (i.e., changing from AIA to pre-AIA ) 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 12-13 are rejected under 35 U.S.C. 103 as being unpatentable over Thom (US 20180077184) in view of Blake (US 20190123895).
Regarding Claim 12, Thom teaches all the limitations of claim 1 above; however, Thom does not explicitly teach wherein a first agent exchanges at least one code sub-module with a second agent to add to or augment a current code base of the first agent.
Blake from same or similar field of endeavor teaches wherein a first agent exchanges at least one code sub-module with a second agent to add to or augment a current code base of the first agent (Paragraph 0141-0144 teach turning to FIG. 4, there is shown a method of recording a change of authorisation state of one or more authorisation agents, from the perspective of a blockchain node; a copy of a blockchain ledger is established at each of a plurality of blockchain nodes, wherein each of the blockchain nodes is associated with a different controlling entity; a public key/private key pair is provided for a first of the blockchain nodes; the private key is stored in a communication device associated with the first controlling entity; the blockchain node receives a first message from the communication device; the first message includes first data indicative of a change of authorisation state of a first authorisation agent associated with the first controlling entity; the first data is encrypted; the first message also includes a digital signature based on the blockchain ledger and the private key; the blockchain node authenticates the message using the public key and then adds a block to the blockchain ledger based on the first message; in this way, a new blockchain ledger is generated that records the change of authorisation state of the first authorisation agent).
It would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Thom to incorporate the teachings of Blake for a first agent to exchange at least one code sub-module with a second agent to add to or augment a current code base of the first agent.
There is motivation to combine Blake into Thom because to increase security, distribution of the new blockchain ledger to the other blockchain nodes may itself involve encryption and/or authentication. For example, each blockchain node may hold its own private key that it uses to encrypt and/or digitally sign new blocks and blockchain ledgers. The public key associated with each private key is distributed to all the other blockchain nodes. This allows each blockchain node to decrypt and/or authenticate a new blockchain ledger that it receives from another of the blockchain nodes (Paragraph 0099).
Regarding Claim 13, the combination of Thom and Blake teaches all the limitations of claims 12 above; however, the combination does not explicitly teach wherein the first agent writes a signed sub-module of code into the decentralized repository, and the second agent extracts the signed sub-module of code from the decentralized repository.
Blake further teaches wherein the first agent writes a signed sub-module of code into the decentralized repository, and the second agent extracts the signed sub-module of code from the decentralized repository (Paragraphs 0134 teaches one or more third parties may be given access to the blockchain ledger so that they may determine or verify authorisation state information such as that listed above; to do this, the third party makes a request to connect and view authorisation state information; the request may be for a specific subset of the available information, such as an item from the above list; the request may be made, for example, via a web page provided by a web server that connects to the relevant blockchain node; the third party may need to establish an account before making the request; the request and any additional information (such as a current time and/or date) are encrypted and digitally signed using a private key that has been issued to the third party, then sent to the relevant blockchain node; a new block comprising the encrypted information and the associated digital signature is added to the blockchain ledger at the blockchain node to form a new blockchain ledger; the new blockchain ledger is distributed to the other blockchain nodes in one of the ways described above).
It would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the combination of Thom and Blake to incorporate the further teachings of Blake for the first agent to write a signed sub-module of code into the decentralized repository, and the second agent extracts the signed sub-module of code from the decentralized repository.
There is motivation to further combine Blake into the combination of Thom and Blake because of the same reasons listed above for claim 12.
Claim 19 is rejected under 35 U.S.C. 103 as being unpatentable over Thom (US 20180077184) over Debendetti (US 20240146756).
Regarding Claim 19, Thom teaches all the limitations of claim 18 above; however, the Thom does not explicitly teach wherein the management at step (b) includes a peer-to-peer computing system adding a digital unit of information which is incorrectly linked to other digital units of information, and the network of distributed software agents searching for and identifying the digital unit of information which is incorrectly linked to other digital units of information, wherein the distributed software agents receive a reward for the identification.
Debendetti from same or similar field of endeavor teaches wherein the management at step (b) includes a peer-to-peer computing system adding a digital unit of information which is incorrectly linked to other digital units of information, and the network of distributed software agents searching for and identifying the digital unit of information which is incorrectly linked to other digital units of information, wherein the distributed software agents receive a reward for the identification (Paragraph 0051 teaches miners compete to achieve the highest confidence level thanks to the distributed consensus algorithm that rewards agreed decisions and penalizes decisions against most of the miners).
It would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Thom to incorporate the teachings of Debendetti for the management at step (b) to include a peer-to-peer computing system adding a digital unit of information which is incorrectly linked to other digital units of information, and the network of distributed software agents searching for and identifying the digital unit of information which is incorrectly linked to other digital units of information, wherein the distributed software agents receive a reward for the identification.
There is motivation to combine Debendetti into Thom because by preventing any fraud or distributed denial of service (DDOS) attack (Debendetti Paragraph 0051).
Claim 20 is rejected under 35 U.S.C. 103 as being unpatentable over Thom (US 20180077184) in view of Pontecorvi (EP 3575953A1).
Regarding Claim 20, Thom teaches all the limitations of claim 1 above; however, Thom does not explicitly teach wherein the management at step (b) comprises: identifying a stored digital unit of the stored digital units that has become mutated; creating a new stored digital unit of information having same identifier as the stored digital unit of information that has become mutated; and marking the new stored digital unit of information as mended in metadata.
Pontecorvi from same or similar field of endeavor teaches wherein the management at step (b) comprises: identifying a stored digital unit of the stored digital units that has become mutated (Paragraphs 0065-0066 teach as patches rely on software dependencies, it is important that the order agreed by the blockchain network peers is maintained; once it is verified that the patch request is the next patch to be applied, the agent determines if the dependencies or prerequisites of that patch are satisfied by the latest status of the network element, as computed above; if so, the patch request is then aborted if it is not the next one in order within the blockchain sequence); creating a new stored digital unit of information having same identifier as the stored digital unit of information that has become mutated (Paragraph 0067 teaches when the protocol does not abort and the patch is applied, the agent then computes the patch report, containing the fingerprints of the resulting hashes after applying validated changes that must be sent to the blockchain network peers for the patch process to be finally validated and completed); and marking the new stored digital unit of information as mended in metadata (Paragraphs 0067 and 0070 teach when the protocol does not abort and the patch is applied, the agent then computes the patch report, containing the fingerprints of the resulting hashes after applying validated changes that must be sent to the blockchain network peers for the patch process to be finally validated and completed; when the HSM is queried by the agent, it may provide a set of hashes corresponding to different components of the monitored device (e.g., BIOS, agent, files, etc.); these hashes represent the integrity certificates that will be included within the patch report and verified against the expected values contained in the blockchain network).
It would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Thom to incorporate the teachings of Pontecorvi for the management at step (b) to comprise: identifying a stored digital unit of the stored digital units that has become mutated; creating a new stored digital unit of information having same identifier as the stored digital unit of information that has become mutated; and marking the new stored digital unit of information as mended in metadata.
There is motivation to combine Pontecorvi into Thom because the interaction between the HSM (e.g., TPMs) and the agent guarantees the security and integrity of the agent 304 and the entirety of the network element being monitored (Pontecorvi Paragraph 0069).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Mehta et al. (US 20200323030) teaches a method and a system for creating and managing a private, decentralized, secure peer-to-peer IP based mesh overlay network. In one embodiment, the mesh network is created comprising at least one gateway node capable of controlling one or more resources connected to the at least one gateway node. A mesh network management server authenticates and provisions the gateway node with a license and firmware for adding to the mesh overlay network and grants ownership of the gateway node to an authorized user. The owner may request for addition or removal of the gateway node or the resources. Each gateway node in the mesh overlay network is configured to share network information of all other gateway nodes, thereby enabling every gateway node to synchronize all of the information of the network, thus creating and managing a mobility resilient, self-healing, plug and play network infrastructure for connecting applications, devices and services for the Internet of Everything (IoE).
De Jesus (US 20200344248) teaches a method of monitoring a computer network, the method comprising: providing a plurality of sensors, wherein said sensors form a meshed network of sensors which monitor cyber-event(s); detecting, by the plurality of sensors, cyber-event(s); linking cyber-event(s) to subsequent cyber-event(s) into branches to form/extend a cyber-event tree; comparing said cyber-event tree to a baseline cyber-event tree; determining if there is any differences in said cyber-event tree to said baseline cyber-event tree to identify a cyber-event tree or a branch thereof as anomalous and thereby identify potential anomalous event(s) and/or a cyber-attack.
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 COURTNEY JONES whose telephone number is (469)295-9137. The examiner can normally be reached on 7:30 am - 4:30 pm CST (M-Th).
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, Neha Patel can be reached at (571) 270-1492. The fax phone number for the organization where this application or proceeding is assigned is (571) 273-8300.
Information regarding the status of an application may be obtained from Patent Center. Status information for published applications may be obtained from Patent Center. Status information for unpublished applications is available through Patent Center for authorized users only. Should you have questions about access to Patent Center, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free).
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) Form at https://www.uspto.gov/patents/uspto-automated- interview-request-air-form.
/COURTNEY P JONES/Primary Examiner, Art Unit 3699
Prosecution Insights