DETAILED ACTION
Response to Amendment
The amendment filed on 16 January 2026 has been entered.
Claims 1-10, 21-30, 41-42 are pending.
Claims 3, 26, 42 are amended.
Applicant’s amendments to the Claims have overcome each and every objection previously set forth in the Non-Final Office Action, mailed 16 October 2025.
Response to Arguments
Applicant's arguments filed on 16 January 2026 have been fully considered, but they are not persuasive.
Applicant’s remarks, regarding the rejections of claims under 35 USC 103, have been fully considered.
Applicant submits for each of the following reasons separately or collectively, Zhao fails to cure the deficiencies of Ramos:
1. Zhao does not teach or suggest: after a determination that the first number of attestation responses does not satisfy a threshold number: identify a second subset of the peer devices that are capable of validating the model, the second subset separate from the first subset;
2. Zhao does not teach or suggest: update the blockchain.
3. Zhao does not teach or suggest: update the blockchain to indicate the model is valid after the threshold number of attestation responses is satisfied.
Accordingly, because the Office Action indicates that Ramos does not teach the noted elements of Claim 1 and, as set forth above, Zhao is also deficient, Claim 1 is patentable over the alleged combination of Ramos and Zhao. Similarly, for at least the foregoing reasons, reconsideration of the rejections of independent Claims 21 and all claims depending therefrom is requested. The deficiencies of Zhao set forth above apply equally to Claim 42.
Examiner respectfully disagrees. In response to Applicant's argument that the references fail to show certain features of the invention, it is noted that the features upon which Applicant relies, under broadest reasonable interpretation (BRI), are given their plain meaning, unless such meaning is inconsistent with the Specification, see MPEP § 2111.01(I).
As outlined in the Non-Final Office Action, mailed 16 October 2025, pg. 8-9, and therein further elaborated, Zhao teaches a decentralized trust management system model, which comprises a rating generation layer, blockchain infrastructure, and cloud area (cf. Zhao, [3 System Model, pg. 316]), the blockchain infrastructure comprising of RSUs (roadside units) collecting ratings and message credibility from participating vehicle clients and adding collected ratings and message credibility into corresponding blocks in order to update the blockchain update the distributed ledger (cf. Zhao, [Blockchain Infrastructure, pg. 317]), in a similar manner to the claimed invention. In addition, the vehicle clients are equipped with on-board sensors, computers and communication devices for data gathering, processing and uploading, in order to receive and interpret messages, similar to the model outlined in the Specification [0020], for the rating calculation process. Dependent on the preset threshold, if a certain percentage of vehicle clients do not exceed the threshold, the event is determined to be fake. If a certain percentage is exceeded, the credibility is determined, resulting in determining whether the vehicle is malicious or not, with calculation results uploaded to the RSUs for updating the blockchain (cf. Zhao, [5.2 Rating Calculation, pg. 319]), similar to update the blockchain to indicate the model is valid after the threshold number of attestation responses is satisfied, claimed by the instant application. Further, this process continues over periods of time, with a number of different messages from different vehicles (cf. Zhao, [5.2 Rating Calculation, pg. 319]), similar to after determination that the first number of attestation responses does not satisfy a threshold number: identify a second subset of the peer devices that are capable of validating the model, the second subset separate from the first subset, claimed by the instant application. Examiner further notes the subsequent subsets of vehicles in the rating calculation process described above are different subsets, each subset used to determine threshold requirements and in order to calculate a percentage, a number of parts is divided by a whole. Therefore, in order to calculate the percentage of vehicles for the threshold requirement, a number of responses from vehicles is determined from each subset of vehicles, the threshold requirement defined to be preset (cf. Zhao, [5.2 Rating Calculation, pg. 319]).
The rejection of Claim 1 under 35 USC 103 has been maintained. Similarly, the rejections of Claims 21, 42 under 35 USC 103 have been maintained.
Rejections of Claims 2-10, 22-30, 41, which depends directly or indirectly from Claims 1, 21 under 35 USC 103 have been maintained.
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 .
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.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
Claims 1-2, 4-9, 21-22, 24-29 are rejected under 35 U.S.C. 103 as being unpatentable over Ramos et al. (U.S. Pre-Grant Publication No. 2019/0166101, hereinafter ‘Ramos'), in view of Zhao et al. (NPL: “Consortium Blockchain-Based Secure Software Defined Vehicular Network”, hereinafter ‘Zhao’).
Regarding claim 1 and analogous claim 21, Ramos teaches A device to propagate a model in an edge architecture, the device comprising: interface circuitry to access a model from the edge architecture, the edge architecture including peer devices; at least one memory; machine-readable instructions; and at least one processor circuit to be programmed by the machine-readable instructions to ([0005] In another example embodiment, provided is a computing system that includes one or more of a interface circuitry to access a model from the edge architecture, the edge architecture including peer devices network interface configured to receive edge data that has been captured by one or more edge devices in an Internet of Things (IoT) network, and a processor configured to encrypt the received edge data, store the encrypted edge data as one or more transactions within a blockchain, and determine that an event has been captured by the received edge data based on metadata of the received edge data. In this example, in response to determining that the event has been captured, the processor may be further configured to generate a notification associated with the event being captured, and control the network interface to output the generated notification for display on a user device.; [0006] In another example embodiment, provided is a non-transitory computer readable medium having stored therein machine-readable instructions program instructions that at least one processor circuit to be programmed by the machine-readable instructions when executed cause a computer to perform one or more of receiving edge data that has been captured by one or more edge devices in an Internet of Things (IoT) network, encrypting the received edge data and storing the encrypted edge data as one or more transactions within a blockchain, determining, by a blockchain node, that an event has been captured by the received edge data based on metadata of the received edge data, and in response to determining that the event has been captured, generating a notification associated with the event being captured and outputting the generated notification for display on a user device.; [0061] The above embodiments may be implemented in hardware, in a computer program executed by a processor, in firmware, or in a combination. A computer program may be embodied on a computer readable medium, such as a storage medium. For example, a computer program may reside in at least one memory random access memory (“RAM”), flash memory, read-only memory (“ROM”), erasable programmable read-only memory (“EPROM”), electrically erasable programmable read-only memory (“EEPROM”), registers, hard disk, a removable disk, a compact disk read-only memory (“CD-ROM”), or any other form of storage medium known in the art.):
determine a first number of attestation responses from a first subset of the peer devices based on a blockchain associated with the model ([0030] In this example, IoT may be used as an overall architecture of the system 100 for acquiring information using smart devices/cameras 112, ingesting the acquired information into the cloud platform 120 using IoT protocol, further processing the data and distributing the results via blockchain node 130 to interested parties such as management device 140 which may correspond to a corporation, a government party, an authority, and the like. According to various aspects, the based on a blockchain associated with the model blockchain node 130 includes cognitive capabilities capable of identifying and confirming that events (e.g., crimes, infractions, accidents, etc.) have been detected by edge devices. Blockchains are distributed databases with built-in pre-agreed technical and/or business logic criteria which is referred to as a smart contract. The blockchain stored by the blockchain node 130 may be synchronized with a replica of the blockchain stored by other blockchain nodes (not shown) through consensus and replication processes. Furthermore, each blockchain node 130 may include a smart contract as described herein which has cognitive capabilities.; [0033] The smart contract may cognitively determine a first number of attestation responses from a first subset of the peer devices determine or verify that an event has been detected by the edge devices 112 and trigger notification to authorized parties such as law enforcement 140. The smart contract may determine a confidence level or amount that the event has occurred based on various attributes of the received data and metadata associated with the received data. When the confidence reaches a predetermined threshold, the smart contract may trigger the notification to the management entity device 140.); and
Ramos fails to teach after a determination that the first number of attestation responses does not satisfy a threshold number: identify a second subset of the peer devices that are capable of validating the model, the second subset separate from the first subset; identify a second number of attestation responses needed from the second subset to satisfy the threshold number; cause transmission of the model to a portion of the second subset of the peer devices, the portion based on a remaining number of attestation responses needed to satisfy the threshold number; and update the blockchain to indicate the model is valid after the threshold number is satisfied.
Zhao teaches after a determination that the first number of attestation responses does not satisfy a threshold number: identify a second subset of the peer devices that are capable of validating the model, the second subset separate from the first subset; identify a second number of attestation responses needed from the second subset to satisfy the threshold number; cause transmission of the model to a portion of the second subset of the peer devices, the portion based on a remaining number of attestation responses needed to satisfy the threshold number; and update the blockchain to indicate the model is valid after the threshold number is satisfied ([5.2 Rating calculation, pg. 319-320] A vehicle might receive diverse traffic-relevant messages from different vehicles in a certain time interval. We assume there are M kinds of road-relevant events in total, and the number of vehicles in reference set is J . A receiver will separate all receiving messages from the reference set into identify a second number of attestation responses needed from the second subset M groups, i.e., {g1, g2, ..., gM}. Each group is a set of vehicles which have reported a specific message ei (e.g., there is a traffic jam at road segment A or there is no traffic jam at road segment A). Whereas not all vehicles in the same group have the equal message credibility, the receiving time and the distance from reporter to event position will significantly influence the message credibility.; We to satisfy the threshold number define a preset threshold T hr, if identify a second subset of the peer devices that are capable of validating the model, the second subset separate from the first subset a certain percentage reported-vehicles after a determination that the first number of attestation responses does not satisfy a threshold number do not exceed the threshold, we can reckon this event is fake. If exceed, we then cause transmission of the model to a portion of the second subset of the peer devices, the portion based on a remaining number of attestation responses needed to satisfy the threshold number calculate the floating message credibility range of a specific event according to Eq. 6. If there exists a message credibility exceed or below this floating range, we can reckon the reported vehicle is malicious. If the number of vehicles in the floating range is majority compared with the number of reported vehicles, then, we can update the blockchain to indicate the model is valid after the threshold number is satisfied recognize the message k is true. In a period of time, a receiver might receive different types of messages from different vehicles. We define the rating of a specific vehicle is the percentage of correct events reported by this vehicle accounts for the proportion of the number of all reported incidents.).
Ramos and Zhao are considered to be analogous to the claimed invention because they are in the same field of blockchain transactions. In view of the teachings of Ramos, it would have been obvious for a person of ordinary skill in the art to apply the teachings of Zhao to Ramos before the effective filing date of the claimed invention in order to increase the efficiency of resource allocation, converting multiple-path mapping problem of the virtual network into the multi-commodity flow problem, solved by a heuristic algorithm (cf. Zhao, [Abstract, pg. 314] In this paper, we associate resources allocation problem with trust value of vehicles for the first time. The trust value of vehicles can be obtained through trust management system. Considering that there are many defects in the state-in-art trust management schemes, in this paper, a decentralized trust management architecture is designed which constitutes of three layers based on consortium blockchain. A joint proof-of-stake and modified practical Byzantine fault tolerance (PoS-mPBFT) algorithm is proposed to the shorten the confirmation time, which is deployed on RSUs. Different from previous researches that focus on designing methods to evaluate trust value, we use prediction model to estimate trust value of vehicles in the next period. After calculating trust value of vehicles, it assigns more resources to those high credibility vehicles when SDN services are provided. Meanwhile, to increase the efficiency of resource allocation, we convert the multiple-path mapping problem of the virtual network into the multi-commodity flow problem, which is solved by a heuristic algorithm. The simulation results indicate that the proposed trust management architecture and heuristic algorithm could provide better safety in SDVN and shorten consensus time, meanwhile effectively abstract underlying resources to enhance network load balance and capacity.).
Regarding claim 2 and analogous claim 22, Ramos, as modified by Zhao, teaches The device of claim 1 and The at least one non-transitory computer readable medium of claim 21, respectively.
Ramos teaches wherein one or more of the at least one processor circuit is to: obtain sensor data; execute the model with the sensor data to obtain a model output; and cause an action to be taken in response to the model output ([0022] The instant application in one embodiment relates to blockchain transactions, and in another embodiment relates to a cognitive blockchain system which is implemented within an Internet of Things (IoT) network. In some embodiments, the blockchain system maintains or otherwise protects personal privacy of its users that provide data and that are included within the data while allowing for specific data captured by an edge device to be externalized and viewed when it satisfies specific characteristics defined by a blockchain smart contract. Data such as images, temperature measurements, particle and emission outputs, and the like, may be captured by edge devices such as traffic light cameras, user devices (crowdsourcing), obtain sensor data sensors, dashboard cameras, and the like, and transmitted to a blockchain node of the cognitive blockchain system. The data may capture an event that has occurred such as a person or an object (e.g., a vehicle, automobile, etc.) committing a violation or a crime, involved in an accident, and the like. Within a execute the model with the sensor data to obtain a model output smart contract of the blockchain may exist cognitive capabilities that can detect when an event has occurred, and what details to cause an action to be taken in response to the model output output to an authority when the event occurs.).
Ramos and Zhao are combinable for the same rationale as set forth above with respect to claim 1.
Regarding claim 4 and analogous claim 24, Ramos, as modified by Zhao, teaches The device of claim 1 and The at least one non-transitory computer readable medium of claim 21, respectively.
Ramos teaches wherein one or more of the at least one processor circuit is to cause the peer devices to evaluate respective validation credentials and execute the model when the respective one of the peer devices is qualified to validate the model based on validation credentials ([0040] FIG. 2 illustrates a blockchain system database configuration, according to example embodiments. Referring to FIG. 2, blockchain system 200 may include certain common blockchain elements, for example, a group 280 of assigned peer blockchain nodes 281-284 which participate in blockchain transaction addition and validation process (consensus).; [0051] As IoT data is transmitted to the blockchain network 420, a blockchain node included within the blockchain network 420 may receive the IoT data and the smart contract executing therein may perform different anonymizations on the data. As shown in 400B of FIG. 4B, the blockchain node/smart contract may generate a table 450 that cause the peer devices to evaluate respective validation credentials and execute the model when the respective one of the peer devices is qualified to validate the model based on validation credentials identifies an edge device using a unique transaction key that is assigned by the blockchain node/smart contract to each user device. The unique transaction key can be used by the edge device to sign captured IoT data each time the edge device transmits captured data to the blockchain network. When the data is received, an identity of the user device (e.g., IMEI, name, password, serial number, email, phone number, etc.) may be replaced with the unique transaction key assigned to the user device. Accordingly, the unique transaction key may be stored by the blockchain instead of the identity of the user device. The blockchain node may maintain an actual identity of the edge device (e.g., in an inaccessible storage) but keep the actual identity hidden from public view and from the authority/corporate view. The blockchain node may also maintain metadata of the captured data within the table such as an amount of data captured by each device, a geographical location of the device, a time at which the data was captured, a level of confidence associated with the device.).
Ramos and Zhao are combinable for the same rationale as set forth above with respect to claim 1.
Regarding claim 5, Ramos, as modified by Zhao, teaches The device of claim 1.
Ramos teaches wherein ones of the peer devices are to update the blockchain associated with the model with an attestation of the model based on the execution of the model ([0003] A blockchain may be used as a public ledger to store transaction information involving digital assets and the like. Because any individual or entity can often provide information to a blockchain, this information should be reviewed and confirmed. This operation is known as consensus. There are two types of consensus centralized and decentralized. Centralized consensus includes one central database that is used to rule transaction validity. A decentralized consensus transfers authority and trust to a decentralized network and wherein ones of the peer devices are to update the blockchain associated with the model with an attestation of the model based on the execution of the model enables its nodes to continuously and sequentially record their transactions on a public “block”, creating a unique “chain” referred to as a blockchain. Cryptography, via hash codes, is used with a blockchain to secure an authentication of a transaction source and removes the need for a central intermediary.; [0040] FIG. 2 illustrates a blockchain system database configuration, according to example embodiments. Referring to FIG. 2, blockchain system 200 may include certain common blockchain elements, for example, a group 280 of assigned peer blockchain nodes 281-284 which participate in blockchain transaction addition and validation process (consensus). As an example, the blockchain node 130 shown in FIG. 1 may be one of the peer blockchain nodes 281-284, etc. Any of the blockchain peer nodes 280 may initiate a blockchain authentication and seek to write to a blockchain immutable ledger stored in blockchain layer 220, a copy of which may also be stored on the underpinning physical infrastructure 210. In this configuration, the customized blockchain configuration may include one or applications 270 which are linked to application programming interfaces (APIs) 260 to access and execute stored program/application code (e.g., chain code and/or smart contracts) 250, which are created according to the customized configuration sought by the participants and can maintain their own state, control its own assets, and receive external information. This code can be deployed as a transaction and installed, via appending to the distributed ledger, on all blockchain peer nodes.).
Ramos and Zhao are combinable for the same rationale as set forth above with respect to claim 1.
Regarding claim 6, Ramos, as modified by Zhao, teaches The device of claim 1.
Ramos teaches wherein the model is a first model, and one or more of the at least one processor circuit is to: obtain a second model from a remote edge appliance; determine the device is qualified to validate the second model based on validation credentials; initiate an execution of the second model; and cause transmission, over the edge architecture, of an attestation response of the second model based on the execution of the second model ([0015] FIGS. 4A-4B are diagrams illustrating a blockchain anonymizing edge data from multiple different edge devices in accordance with example embodiments.; [0023] According to various embodiments, the edge data may be anonymized by the blockchain system. However, the blockchain may determine if the device is qualified to validate the second model based on validation credentials assign a unique transaction key to each respective edge device to be used by the edge device to sign captured data sent to the blockchain thereby enabling the blockchain to verify the information is received from a trusted source. Accordingly, the blockchain may maintain a record of where and who provided the data based on the unique transaction key signature, while also shielding the user/device that captured the data. In addition, the blockchain may remove or otherwise anonymize details from the data captured (e.g., removing image data) that is not relevant to a particular event such as a crime thereby removing information about innocent bystanders. For example, the anonymization process may extract specific details (e.g., a license plate, a face, a vehicle, a victim, etc.) of an event while preventing other details from being revealed thereby maintain privacy of individuals out in public environments as well as maintaining a privacy of the user or the entity that captured the edge data.; [0024] The smart contract executing on the blockchain node can encrypt the data received from the edge devices and store the data in the cognitive blockchain. Here, the ability to decrypt the encrypted edge data may be maintained within the blockchain itself (i.e., a smart contract on a blockchain node) thereby protecting the data from being accessed publicly or by anyone other than the blockchain. Furthermore, the smart contract may also perform cognitive analysis on the received data prior to the data being encrypted and stored in the blockchain. For example, the smart contract may cognitively identify situations or other events that have occurred in which the encrypted (i.e., protected) data should be made available to specifically authorized parties such as corporations, authorities, and the like. The smart contract can analyze the received data as well as metadata associated with the received data and determine a level of confidence that an event has occurred based on the data. When the confidence has reached a predetermined threshold, the smart contract may be satisfied that the event has occurred and output a notification concerning the event to an authority device/system.; [0025] For example, a single edge device capturing data of a possible violation may be a false positive and may not be enough to warrant an event determination by the cognitive blockchain. However, obtain a second model from a remote edge appliance more than one edge device initiate an execution of the second model when the device is qualified capturing the same violation (e.g., two or more) may improve the confidence of the smart contract determination. Furthermore, cause transmission, over the edge architecture, of an attestation response of the second model based on the execution of the second model metadata associated with images/data captured by the edge devices may be used to improve the confidence of the event detection. For example, the metadata of the captured data may include a geographical location at which the data was captured, a time when the data was captured, a level of trust associated with the device that captured the data (e.g., private citizen vs. authority), an amount of devices, a type of event detected, a severity of the event, an urgency of the event, and the like, which may be used to further determine the level of confidence. When the confidence reaches or exceeds a predetermined threshold, the cognitive smart contract may make a positive determination that the event has occurred and output information about the event to an authority.).
Ramos and Zhao are combinable for the same rationale as set forth above with respect to claim 1.
Regarding claim 7 and analogous claim 27, Ramos, as modified by Zhao, teaches The device of claim 6 and The at least one non-transitory computer readable medium of claim 26, respectively.
Ramos teaches wherein the validation credentials are based on the second model ([0025] For example, a single edge device capturing data of a possible violation may be a false positive and may not be enough to warrant an event determination by the cognitive blockchain. However, more than one edge device based on the second model capturing the same violation (e.g., two or more) may improve the confidence of the smart contract determination. Furthermore, metadata associated with images/data captured by the edge devices may be used to improve the confidence of the event detection. For example, the metadata of the captured data may include a geographical location at which the data was captured, a time when the data was captured, a level of trust associated with the device that captured the data (e.g., private citizen vs. authority), an amount of devices, a type of event detected, a severity of the event, an urgency of the event, and the like, which may be used to further determine the level of confidence. When the confidence reaches or exceeds a predetermined threshold, the cognitive smart contract may make a positive determination that the event has occurred and output information about the event to an authority.; [0038] In some embodiments, a single edge device 112 providing information may not have enough trust to trigger alerts. The validation credentials cognitive smart contract can increase triggering confidence as the number of edge devices capturing the event (e.g., crowd size) increases hence reducing false positives. False positives can be due to devices turned rogue, hacked or misused or error in image processing. As a non-limiting example, if two device report an infraction, the smart contract may assign a weight of 5% confidence that the infraction occurred. As another example, if five devices report information corroborating the same infraction, then confidence or certainty could be 60%, but if ten devices report pertinent information to an infraction the confidence may be 100%.).
Ramos and Zhao are combinable for the same rationale as set forth above with respect to claim 1.
Regarding claim 8, Ramos, as modified by Zhao, teaches The device of claim 6.
Ramos teaches wherein the attestation response includes one or more of a hash or a signature of the device included in a blockchain associated with the second model ([0023] According to various embodiments, the edge data may be anonymized by the blockchain system. However, the blockchain may attestation response includes signature of the device included in a blockchain associated with the second model assign a unique transaction key to each respective edge device to be used by the edge device to sign captured data sent to the blockchain thereby enabling the blockchain to verify the information is received from a trusted source. Accordingly, the blockchain may maintain a record of where and who provided the data based on the unique transaction key signature, while also shielding the user/device that captured the data. In addition, the blockchain may remove or otherwise anonymize details from the data captured (e.g., removing image data) that is not relevant to a particular event such as a crime thereby removing information about innocent bystanders. For example, the anonymization process may extract specific details (e.g., a license plate, a face, a vehicle, a victim, etc.) of an event while preventing other details from being revealed thereby maintain privacy of individuals out in public environments as well as maintaining a privacy of the user or the entity that captured the edge data.; [0042] The blockchain configuration of FIG. 2 may process and execute program/application code 250 by way of one or more interfaces exposed, and services provided, by blockchain platform 205. The code may control blockchain assets. For example, the code can store and transfer data, and may be executed by the blockchain in the form of a smart contract and associated chain code with conditions or other code elements subject to its execution. The smart contracts 250 may be created to execute reminders, updates, and/or other notifications subject to the changes, updates, etc. The smart contracts can themselves be used to identify rules associated with authorization and access requirements and usage. For example, one or more of a hash hashed identifier information 252 received from a user device may be processed by one or more processing entities (virtual machines) included in the blockchain layer 220. The result may include access being granted 254 to a third party application from the blockchain computing environment (VM). In this example, the previously known user identifiers or data template information may be stored in the blockchain platform 205. The physical machines 210 may be accessed to retrieve the user device template and the information can be used to match against incoming user identifiers for verification purposes.).
Ramos and Zhao are combinable for the same rationale as set forth above with respect to claim 1.
Regarding claim 9 and analogous claim 29, Ramos, as modified by Zhao, teaches The device of claim 6 and The at least one non-transitory computer readable medium of claim 26, respectively.
Ramos teaches wherein one or more of the at least one processor circuit is to access sensor data and use the sensor data to initiate the execution of the second model, the attestation response includes one or more of a hash or a signature of the sensor data included in a blockchain associated with the second model ([0022] The instant application in one embodiment relates to blockchain transactions, and in another embodiment relates to a cognitive blockchain system which is implemented within an Internet of Things (IoT) network. In some embodiments, the blockchain system maintains or otherwise protects personal privacy of its users that provide data and that are included within the data while allowing for specific data captured by an edge device to be externalized and viewed when it satisfies specific characteristics defined by a blockchain smart contract. Data such as images, temperature measurements, particle and emission outputs, and the like, may be captured by edge devices such as traffic light cameras, user devices (crowdsourcing), access sensor data gathered by the device sensors, dashboard cameras, and the like, and transmitted to a blockchain node of the cognitive blockchain system. The data may capture an event that has occurred such as a person or an object (e.g., a vehicle, automobile, etc.) committing a violation or a crime, involved in an accident, and the like. Within a smart contract of the blockchain may exist cognitive capabilities that can detect when an event has occurred, and what details to output to an authority when the event occurs.; [0023] According to various embodiments, the edge data may be anonymized by the blockchain system. However, the blockchain may assign a unique transaction key to each respective edge device to be used by the edge device to use the sensor data to initiate the execution of the second model sign captured data sent to the blockchain thereby enabling the blockchain to verify the information is received from a trusted source. Accordingly, the blockchain may maintain a attestation response includes one or more of a hash or a signature of the sensor data included in a blockchain associated with the second model record of where and who provided the data based on the unique transaction key signature, while also shielding the user/device that captured the data. In addition, the blockchain may remove or otherwise anonymize details from the data captured (e.g., removing image data) that is not relevant to a particular event such as a crime thereby removing information about innocent bystanders. For example, the anonymization process may extract specific details (e.g., a license plate, a face, a vehicle, a victim, etc.) of an event while preventing other details from being revealed thereby maintain privacy of individuals out in public environments as well as maintaining a privacy of the user or the entity that captured the edge data.).
Ramos and Zhao are combinable for the same rationale as set forth above with respect to claim 1.
Regarding claim 25, Ramos, as modified by Zhao, teaches The at least one non-transitory computer readable medium of claim 21.
Ramos teaches wherein the machine-readable instructions cause one or more of the at least one processor circuit to supplement the blockchain associated with the model based on an attestation of the model corresponding to the execution of the model ([0003] A blockchain may be used as a public ledger to store transaction information involving digital assets and the like. Because any individual or entity can often provide information to a blockchain, this information should be reviewed and confirmed. This operation is known as consensus. There are two types of consensus centralized and decentralized. Centralized consensus includes one central database that is used to rule transaction validity. A decentralized consensus transfers authority and trust to a decentralized network and enables its nodes to supplement the blockchain associated with the model based on an attestation of the model corresponding to the execution of the model continuously and sequentially record their transactions on a public “block”, creating a unique “chain” referred to as a blockchain. Cryptography, via hash codes, is used with a blockchain to secure an authentication of a transaction source and removes the need for a central intermediary.; [0040] FIG. 2 illustrates a blockchain system database configuration, according to example embodiments. Referring to FIG. 2, blockchain system 200 may include certain common blockchain elements, for example, a group 280 of assigned peer blockchain nodes 281-284 which participate in blockchain transaction addition and validation process (consensus). As an example, the blockchain node 130 shown in FIG. 1 may be one of the peer blockchain nodes 281-284, etc. Any of the blockchain peer nodes 280 may initiate a blockchain authentication and seek to write to a blockchain immutable ledger stored in blockchain layer 220, a copy of which may also be stored on the underpinning physical infrastructure 210. In this configuration, the customized blockchain configuration may include one or applications 270 which are linked to application programming interfaces (APIs) 260 to access and execute stored program/application code (e.g., chain code and/or smart contracts) 250, which are created according to the customized configuration sought by the participants and can maintain their own state, control its own assets, and receive external information. This code can be deployed as a transaction and installed, via appending to the distributed ledger, on all blockchain peer nodes.).
Ramos and Zhao are combinable for the same rationale as set forth above with respect to claim 1.
Regarding claim 26, Ramos, as modified by Zhao, teaches The at least one non-transitory computer readable medium of claim 21.
Ramos teaches wherein the model is a first model, and the machine-readable instructions cause one or more of the at least one processor circuit to: obtain a second model from a remote edge appliance; determine one of the peer devices is qualified to validate the second model based on validation credentials; initiate an execution of the second model when the one of the peer devices is qualified; and cause transmission, over an edge architecture, an attestation of the second model based on the execution of the second model ([0015] FIGS. 4A-4B are diagrams illustrating a blockchain anonymizing edge data from multiple different edge devices in accordance with example embodiments.; [0023] According to various embodiments, the edge data may be anonymized by the blockchain system. However, the blockchain may determine one of the peer devices is qualified to validate the second model based on validation credentials assign a unique transaction key to each respective edge device to be used by the edge device to sign captured data sent to the blockchain thereby enabling the blockchain to verify the information is received from a trusted source. Accordingly, the blockchain may maintain a record of where and who provided the data based on the unique transaction key signature, while also shielding the user/device that captured the data. In addition, the blockchain may remove or otherwise anonymize details from the data captured (e.g., removing image data) that is not relevant to a particular event such as a crime thereby removing information about innocent bystanders. For example, the anonymization process may extract specific details (e.g., a license plate, a face, a vehicle, a victim, etc.) of an event while preventing other details from being revealed thereby maintain privacy of individuals out in public environments as well as maintaining a privacy of the user or the entity that captured the edge data.; [0024] The smart contract executing on the blockchain node can encrypt the data received from the edge devices and store the data in the cognitive blockchain. Here, the ability to decrypt the encrypted edge data may be maintained within the blockchain itself (i.e., a smart contract on a blockchain node) thereby protecting the data from being accessed publicly or by anyone other than the blockchain. Furthermore, the smart contract may also perform cognitive analysis on the received data prior to the data being encrypted and stored in the blockchain. For example, the smart contract may cognitively identify situations or other events that have occurred in which the encrypted (i.e., protected) data should be made available to specifically authorized parties such as corporations, authorities, and the like. The smart contract can analyze the received data as well as metadata associated with the received data and determine a level of confidence that an event has occurred based on the data. When the confidence has reached a predetermined threshold, the smart contract may be satisfied that the event has occurred and output a notification concerning the event to an authority device/system.; [0025] For example, a single edge device capturing data of a possible violation may be a false positive and may not be enough to warrant an event determination by the cognitive blockchain. However, obtain a second model from a remote edge appliance more than one edge device initiate an execution of the second model when the one of the peer devices is qualified capturing the same violation (e.g., two or more) may improve the confidence of the smart contract determination. Furthermore, cause transmission, over an edge architecture, an attestation of the second model based on the execution of the second model metadata associated with images/data captured by the edge devices may be used to improve the confidence of the event detection. For example, the metadata of the captured data may include a geographical location at which the data was captured, a time when the data was captured, a level of trust associated with the device that captured the data (e.g., private citizen vs. authority), an amount of devices, a type of event detected, a severity of the event, an urgency of the event, and the like, which may be used to further determine the level of confidence. When the confidence reaches or exceeds a predetermined threshold, the cognitive smart contract may make a positive determination that the event has occurred and output information about the event to an authority.).
Ramos and Zhao are combinable for the same rationale as set forth above with respect to claim 1.
Regarding claim 28, Ramos, as modified by Zhao, teaches The at least one non-transitory computer readable medium of claim 26.
Ramos teaches wherein the attestation includes one or more of a hash or a signature of the one of the peer devices included in a blockchain associated with the second model ([0023] According to various embodiments, the edge data may be anonymized by the blockchain system. However, the blockchain may attestation includes one or more of a hash or a signature of the one of the peer devices included in a blockchain associated with the second model assign a unique transaction key to each respective edge device to be used by the edge device to sign captured data sent to the blockchain thereby enabling the blockchain to verify the information is received from a trusted source. Accordingly, the blockchain may maintain a record of where and who provided the data based on the unique transaction key signature, while also shielding the user/device that captured the data. In addition, the blockchain may remove or otherwise anonymize details from the data captured (e.g., removing image data) that is not relevant to a particular event such as a crime thereby removing information about innocent bystanders. For example, the anonymization process may extract specific details (e.g., a license plate, a face, a vehicle, a victim, etc.) of an event while preventing other details from being revealed thereby maintain privacy of individuals out in public environments as well as maintaining a privacy of the user or the entity that captured the edge data.; [0042] The blockchain configuration of FIG. 2 may process and execute program/application code 250 by way of one or more interfaces exposed, and services provided, by blockchain platform 205. The code may control blockchain assets. For example, the code can store and transfer data, and may be executed by the blockchain in the form of a smart contract and associated chain code with conditions or other code elements subject to its execution. The smart contracts 250 may be created to execute reminders, updates, and/or other notifications subject to the changes, updates, etc. The smart contracts can themselves be used to identify rules associated with authorization and access requirements and usage. For example, one or more of a hash hashed identifier information 252 received from a user device may be processed by one or more processing entities (virtual machines) included in the blockchain layer 220. The result may include access being granted 254 to a third party application from the blockchain computing environment (VM). In this example, the previously known user identifiers or data template information may be stored in the blockchain platform 205. The physical machines 210 may be accessed to retrieve the user device template and the information can be used to match against incoming user identifiers for verification purposes.).
Ramos and Zhao are combinable for the same rationale as set forth above with respect to claim 1.
Claims 3, 10, 23, 30, 41 are rejected under 35 U.S.C. 103 as being unpatentable over Ramos, in view of Zhao, and further in view of Murphy et al. (U.S. Pre-Grant Publication No. 2023/0308518, hereinafter ‘Murphy’).
Regarding claim 3, Ramos, as modified by Zhao, teaches The device of claim 1.
Ramos, as modified by Zhao, fails to teach wherein, after transmission of the model to the portion of the second subset of the peer devices, one or more of the at least one processor circuit is to: determine a third number of attestation responses based on the blockchain associated with the model; and determine the model is verified based on the third number satisfying the threshold number.
Murphy teaches wherein, after transmission of the model to the portion of the second subset of the peer devices, one or more of the at least one processor circuit is to: determine a third number of attestation responses based on the blockchain associated with the model; and determine the model is verified based on the third number satisfying the threshold number ([0260] At step 1010, the client device proposes adding the record to the digital ledger. As previously noted, writing or recording data onto the ledger requires that a population of client devices in the network must achieve “consensus”. In one such variant, consensus is achieved when a simple majority of the second fog network (more than 50%) of devices have validated a block for adding to the blockchain. Various other mechanisms may be substituted with equivalent success (e.g., weighted voting, supermajority voting, etc.); [0261] In one embodiment, the second fog network evaluates the proposed block received from the client device, and validates the corresponding proof-of-work (POW). As previously noted, validating a POW can be done quickly (many magnitudes of time faster than generating a POW). The second fog network determine a third number of attestation responses based on the blockchain associated with the model reaches consensus when at least a determine the model is verified based on the third number satisfying the threshold number threshold number or percentage of multiple other client devices validate the record. In one exemplary embodiment, when a device of the second fog network validates a proposed block, it immediately broadcasts the valid block to other devices of the second fog network to validate. In this manner, a proposed block is quickly propagated throughout the second fog network.; [0262] Once consensus is received, the proposed record is added to the distributed ledger at step 1012. In some embodiments, the client device and any devices that have received the ledger add the proposed block to their current copy of the ledger. In some variants, the updated ledger is stored onto a network component (e.g., DU, radio access device, small cell). In some variants, the ledger may also be propagated into other networks by devices that are part of the other network. In other variants, the ledger may be recorded onto a central network entity (e.g., a server, core network, backend apparatus) for other networks or client devices to access.).
Ramos, Zhao, and Murphy are considered to be analogous to the claimed invention because they are in the same field of blockchain transactions. In view of the teachings of Ramos and Zhao, it would have been obvious for a person of ordinary skill in the art to apply the teachings of Murphy to Ramos before the effective filing date of the claimed invention in order to self-organize resource allocations without the benefit of centralized network management and prevent and/or penalize malicious behavior and/or reduce counterparty risk where there are no definitively trusted participants (cf. Murphy, [0073] As described in greater detail hereinafter, the blockchain technology enables a fog network to self-organize resource allocations without the benefit of centralized network management. Moreover, as described in greater detail hereinafter, another benefit of the blockchain technology is that it may specifically prevent and/or penalize malicious behavior and/or reduce counterparty risk where there are no definitively trusted participants. More directly, blockchain data structures can be used to credit and/or debit user contributions among any arbitrary community of user devices without requiring authentication or trust exchanges.).
Regarding claim 10, Ramos, as modified by Zhao, teaches The device of claim 1.
Ramos, as modified by Zhao, fails to teach wherein the peer devices are a first plurality of edge appliances, and one or more of the at least one processor circuit is to: evaluate respective distances between the device and respective ones of a second plurality of edge appliances, the first plurality of edge appliances being a subset of the second plurality of edge appliances; and select the first plurality of edge appliances for receipt of the model based on the respective distances.
Murphy teaches wherein the peer devices are a first plurality of edge appliances, and one or more of the at least one processor circuit is to: evaluate respective distances between the device and respective ones of a second plurality of edge appliances, the first plurality of edge appliances being a subset of the second plurality of edge appliances; and select the first plurality of edge appliances for receipt of the model based on the respective distances ([0234] In another embodiment, at least a threshold number or percentage of multiple other client devices must validate the record in order to reach consensus; i.e., a consensus must be reached for the recorded ledger entry to be added. For example, a new entry by the client device may evaluate respective distances between the device and respective ones of a second plurality of edge appliances, the first plurality of edge appliances being a subset of the second plurality of edge appliances require at least three other devices to validate the record. As another example, the new entry may require over 50% of the devices in the fog network to validate the record. In some variants, a percentage of only a subset of the network need verify the record. In one implementation, the select the first plurality of edge appliances for receipt of the model based on the respective distances subset may be an area determined by physical distance from the client device based on, e.g., a radius determined by GPS signaling.).
Ramos, Zhao, and Murphy are combinable for the same rationale as set forth above with respect to claim 3.
Regarding claim 23, Ramos, as modified by Zhao, teaches The at least one non-transitory computer readable medium of claim 21.
Ramos, as modified by Zhao, fails to teach wherein to determine if the model is verified, the machine-readable instructions cause one or more of the at least one processor circuit to: determine a third number of attestation responses based on the blockchain associated with the model; determine if the third number satisfies the threshold number; and determine the model is verified based on the third number satisfying the threshold.
Murphy teaches wherein to determine if the model is verified, the machine-readable instructions cause one or more of the at least one processor circuit to: determine a third number of attestation responses based on the blockchain associated with the model; determine if the third number satisfies the threshold number; and determine the model is verified based on the third number satisfying the threshold ([0260] At step 1010, the client device proposes adding the record to the digital ledger. As previously noted, writing or recording data onto the ledger requires that a population of client devices in the network must achieve “consensus”. In one such variant, consensus is achieved when a simple majority of the second fog network (more than 50%) of devices have validated a block for adding to the blockchain. Various other mechanisms may be substituted with equivalent success (e.g., weighted voting, supermajority voting, etc.); [0261] In one embodiment, the second fog network evaluates the proposed block received from the client device, and validates the corresponding proof-of-work (POW). As previously noted, validating a POW can be done quickly (many magnitudes of time faster than generating a POW). The second fog network determine a third number of attestation responses based on the blockchain associated with the model reaches consensus when at least a determine if the third number satisfies the threshold number threshold number or percentage of multiple other client devices validate the record. In one exemplary embodiment, when a device of the second fog network validates a proposed block, it immediately broadcasts the valid block to other devices of the second fog network to validate. In this manner, a proposed block is quickly propagated throughout the second fog network.; [0262] determine the model is verified based on the third number satisfying the threshold Once consensus is received, the proposed record is added to the distributed ledger at step 1012. In some embodiments, the client device and any devices that have received the ledger add the proposed block to their current copy of the ledger. In some variants, the updated ledger is stored onto a network component (e.g., DU, radio access device, small cell). In some variants, the ledger may also be propagated into other networks by devices that are part of the other network. In other variants, the ledger may be recorded onto a central network entity (e.g., a server, core network, backend apparatus) for other networks or client devices to access.).
Ramos, Zhao, and Murphy are combinable for the same rationale as set forth above with respect to claim 3.
Regarding claim 30, Ramos, as modified by Zhao, teaches The at least one non-transitory computer readable medium of claim 21.
Ramos, as modified by Zhao, fails to teach wherein the peer devices are edge appliances, and the machine-readable instructions cause one or more of the at least one processor circuit to: evaluate respective distances between ones of the edge appliances; and select respective ones of the edge appliances for receipt of the model based on the respective distances.
Murphy teaches wherein the peer devices are edge appliances, and the machine-readable instructions cause one or more of the at least one processor circuit to: evaluate respective distances between ones of the edge appliances; and select respective ones of the edge appliances for receipt of the model based on the respective distances ([0234] In another embodiment, at least a threshold number or percentage of multiple other client devices must validate the record in order to reach consensus; i.e., a consensus must be reached for the recorded ledger entry to be added. For example, a new entry by the client device may evaluate respective distances between ones of the edge appliances require at least three other devices to validate the record. As another example, the new entry may require over 50% of the devices in the fog network to validate the record. In some variants, a percentage of only a subset of the network need verify the record. In one implementation, the select respective ones of the edge appliances for receipt of the model based on the respective distances subset may be an area determined by physical distance from the client device based on, e.g., a radius determined by GPS signaling.).
Ramos, Zhao, and Murphy are combinable for the same rationale as set forth above with respect to claim 3.
Regarding claim 41, Ramos, as modified by Zhao and Murphy, teaches The device of claim 3.
Zhao teaches wherein after indicating the model is verified, one or more of the at least one processor circuit is to cause transmission of the model to a third subset of peer devices, the third number of peer devices to execute the model ([5.2 Rating calculation, pg. 319-320] A vehicle might receive diverse traffic-relevant messages from different vehicles in a certain time interval. We assume there are M kinds of road-relevant events in total, and the number of vehicles in reference set is J . A receiver will separate all receiving messages from the reference set into M groups, i.e., {g1, g2, ..., gM}. Each group is a set of vehicles which have reported a specific message ei (e.g., there is a traffic jam at road segment A or there is no traffic jam at road segment A). Whereas not all vehicles in the same group have the equal message credibility, the receiving time and the distance from reporter to event position will significantly influence the message credibility.; We define a preset threshold T hr, if a certain percentage reported-vehicles do not exceed the threshold, we can reckon this event is fake. If exceed, we then calculate the floating message credibility range of a specific event according to Eq. 6. If there exists a message credibility exceed or below this floating range, we can reckon the reported vehicle is malicious. If the number of vehicles in the floating range is majority compared with the number of reported vehicles, then, we can wherein after indicating the model is verified recognize the message k is true. In a period of time, a receiver might receive different types of messages from different vehicles. We define the rating of a specific vehicle is the percentage of correct events reported by this vehicle accounts for the proportion of the number of all reported incidents.; [2 Related Works, pg. 315-316] In the decentralized trust management system, a datacentric trust management scheme was proposed in [14], in which one or more of the at least one processor circuit is to cause transmission of the model to a third subset of peer devices, the third number of peer devices to execute the model each receiver will estimate each piece of the received data, and aggregate them to judge the traffic events. This kind of scheme was executed on the vehicle side, whereas the malfunctions might appear due to the limited observation conditions of vehicles. In [9], each RSU was employed for trust management, the RSU collected the rating uploaded by the vehicles and used a specific algorithm to calculate trust value of each vehicle. Whereas the storage information in RSUs might be incomplete and inconsistent which occurs to that the different RSUs may calculate different trust value of the same vehicle.).
Ramos, Zhao, and Murphy are combinable for the same rationale as set forth above with respect to claim 3.
Claim 42 is rejected under 35 U.S.C. 103 as being unpatentable over Ganapavarapu et al. (U.S. Pre-Grant Publication No. 2020/0394552, hereinafter 'Ganapavarapu'), in view of Zhao.
Regarding claim 42, Ganapavarapu teaches A device to propagate a model in an edge architecture, the device comprising: interface circuitry to: access a first model from the edge architecture; and access a second model from the edge architecture; at least one memory; machine-readable instructions; and at least one processor circuit to be programmed by the machine-readable instructions to: execute the first model without local validation of the first model ([0128] The above embodiments may be implemented in hardware, in a computer program executed by a processor, in firmware, or in a combination of the above. A computer program may be embodied on a computer readable medium, such as a storage medium.; [0129] An exemplary storage medium may be coupled to the processor such that the processor may read information from, and write information to, the storage medium. In the alternative, the storage medium may be integral to the processor. The processor and the storage medium may reside in an application specific integrated circuit (“ASIC”). In the alternative, the processor and the storage medium may reside as discrete components; [0057] In one embodiment, such as Google's federated learning, a collaborative process may be required, where training access a first model from the edge architecture; and access a second model from the edge architecture participants 104 train a common model. The training aggregator 132 collects gradient calculations 136 from the training participants 104 and combines them to create an aggregate model. The training aggregator 132 may be a special type of training participant 104 that is responsible for execute the first model without local validation of the first model collecting inputs (such as gradients) from different training participants 104 and apply them to the model being collectively trained. It is desirable to enable verification of updates in this distributed machine learning setting in order to ensure that no training participant 104 is cheating. Model parameters 136 specify/describe a model in mathematical terms. These parameters 136 are used during prediction. In collaborative machine learning applications, there may be multiple training participants 104 contributing their own individual datasets 108.);
Ganapavarapu fails to teach determine a first number of attestation responses from a first subset of edge devices based on a blockchain associated with the second model; and in response to the first number not satisfying a threshold number: perform execution of the second model with a second subset of edge devices that include data capable of validating the second model; determine the second model is valid based on the execution of the second model; update the blockchain with an attestation response; and cause transmission of the second model to an edge appliance.
Zhao teaches determine a first number of attestation responses from a first subset of edge devices based on a blockchain associated with the second model; and in response to the first number not satisfying a threshold number: perform execution of the second model with a second subset of edge devices that include data capable of validating the second model; determine the second model is valid based on the execution of the second model; update the blockchain with an attestation response; and cause transmission of the second model to an edge appliance ([5.2 Rating calculation, pg. 319-320] A vehicle might receive diverse traffic-relevant messages from different vehicles in a certain time interval. We assume there are M kinds of road-relevant events in total, and the number of vehicles in reference set is J . A determine a first number of attestation responses from a first subset of edge devices based on a blockchain associated with the second model receiver will separate all receiving messages from the reference set into M groups, i.e., {g1, g2, ..., gM}. Each group is a set of vehicles which have reported a specific message ei (e.g., there is a traffic jam at road segment A or there is no traffic jam at road segment A). Whereas not all vehicles in the same group have the equal message credibility, the receiving time and the distance from reporter to event position will significantly influence the message credibility.; We define a preset threshold T hr, perform execution of the second model with a second subset of edge devices that include data capable of validating the second model if a certain percentage reported-vehicles in response to the first number not satisfying a threshold number do not exceed the threshold, we can reckon this event is fake. If determine the second model is valid based on the execution of the second model exceed, we then calculate the floating message credibility range of a specific event according to Eq. 6. If there exists a message credibility exceed or below this floating range, we can reckon the reported vehicle is malicious. If the number of vehicles in the floating range is majority compared with the number of reported vehicles, then, we can update the blockchain with an attestation response recognize the message k is true. In a period of time, a receiver might receive different types of messages from different vehicles. We define the rating of a specific vehicle is the percentage of correct events reported by this vehicle accounts for the proportion of the number of all reported incidents.; [2 Related Works, pg. 315-316] In the decentralized trust management system, a datacentric trust management scheme was proposed in [14], in which cause transmission of the second model to an edge appliance each receiver will estimate each piece of the received data, and aggregate them to judge the traffic events. This kind of scheme was executed on the vehicle side, whereas the malfunctions might appear due to the limited observation conditions of vehicles. In [9], each RSU was employed for trust management, the RSU collected the rating uploaded by the vehicles and used a specific algorithm to calculate trust value of each vehicle. Whereas the storage information in RSUs might be incomplete and inconsistent which occurs to that the different RSUs may calculate different trust value of the same vehicle.).
Ganapavarapu and Zhao are considered to be analogous to the claimed invention because they are in the same field of blockchain transactions. In view of the teachings of Ganapavarapu, it would have been obvious for a person of ordinary skill in the art to apply the teachings of Zhao to Ganapavarapu before the effective filing date of the claimed invention in order to increase the efficiency of resource allocation, converting multiple-path mapping problem of the virtual network into the multi-commodity flow problem, solved by a heuristic algorithm (cf. Zhao, [Abstract, pg. 314] In this paper, we associate resources allocation problem with trust value of vehicles for the first time. The trust value of vehicles can be obtained through trust management system. Considering that there are many defects in the state-in-art trust management schemes, in this paper, a decentralized trust management architecture is designed which constitutes of three layers based on consortium blockchain. A joint proof-of-stake and modified practical Byzantine fault tolerance (PoS-mPBFT) algorithm is proposed to the shorten the confirmation time, which is deployed on RSUs. Different from previous researches that focus on designing methods to evaluate trust value, we use prediction model to estimate trust value of vehicles in the next period. After calculating trust value of vehicles, it assigns more resources to those high credibility vehicles when SDN services are provided. Meanwhile, to increase the efficiency of resource allocation, we convert the multiple-path mapping problem of the virtual network into the multi-commodity flow problem, which is solved by a heuristic algorithm. The simulation results indicate that the proposed trust management architecture and heuristic algorithm could provide better safety in SDVN and shorten consensus time, meanwhile effectively abstract underlying resources to enhance network load balance and capacity.).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Rawat et al. (NPL: “Decentralized Firmware Attestation for In-Vehicle Networks”) teaches a decentralized firmware attestation scheme for the automotive domain.
THIS ACTION IS MADE FINAL. 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 MAGGIE MAIDO whose telephone number is (703) 756-1953. The examiner can normally be reached M-Th: 6am - 4pm.
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, Michael Huntley can be reached on (303) 297-4307. 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.
/MM/Examiner, Art Unit 2129
/MICHAEL J HUNTLEY/Supervisory Patent Examiner, Art Unit 2129