DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
This office action is in response to the applicant’s filing on 02/06/2025. Claims 1-10 are pending. Claims 1, 5, and 8 are independent.
Priority
Acknowledgement is made of applicant’s claiming of priority, as a 371, to International Patent Application No. PCT/EP2023/072424 filed on 08/15/2023 which claims priority to EP22210895.3 filed on 12/01/2022 and PCT/CN2022/113588 filed on 08/19/2022.
Information Disclosure Statement
The information disclosure statement (IDS) submitted on 02/06/2025 is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 8-10 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Claim 8 recites “… (Cn, DTn),” and it is unclear what these pair of elements refers to in the claim. Given the specification and what’s described with regard to Fig. 1 it appears C refers to a config and DT refers to a datetime. The claim should be amended to make it clear (Cn, DTn) is referring to pairs of a config associated with a datetime. Claims 9-10 inherit the defect of claim 8 and are rejected for the same reasons.
Claim Interpretation
The following is a quotation of 35 U.S.C. 112(f):
(f) Element in Claim for a Combination. – An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The following is a quotation of pre-AIA 35 U.S.C. 112, sixth paragraph:
An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The claims in this application are given their broadest reasonable interpretation using the plain meaning of the claim language in light of the specification as it would be understood by one of ordinary skill in the art. The broadest reasonable interpretation of a claim element (also commonly referred to as a claim limitation) is limited by the description in the specification when 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is invoked.
As explained in MPEP § 2181, subsection I, claim limitations that meet the following three-prong test will be interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph:
(A) the claim limitation uses the term “means” or “step” or a term used as a substitute for “means” that is a generic placeholder (also called a nonce term or a non-structural term having no specific structural meaning) for performing the claimed function;
(B) the term “means” or “step” or the generic placeholder is modified by functional language, typically, but not always linked by the transition word “for” (e.g., “means for”) or another linking word or phrase, such as “configured to” or “so that”; and
(C) the term “means” or “step” or the generic placeholder is not modified by sufficient structure, material, or acts for performing the claimed function.
Use of the word “means” (or “step”) in a claim with functional language creates a rebuttable presumption that the claim limitation is to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites sufficient structure, material, or acts to entirely perform the recited function.
Absence of the word “means” (or “step”) in a claim creates a rebuttable presumption that the claim limitation is not to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is not interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites function without reciting sufficient structure, material or acts to entirely perform the recited function.
Claim limitations in this application that use the word “means” (or “step”) are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action. Conversely, claim limitations in this application that do not use the word “means” (or “step”) are not being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action.
This application includes one or more claim limitations that do not use the word “means,” but are nonetheless being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, because the claim limitation(s) uses a generic placeholder that is coupled with functional language without reciting sufficient structure to perform the recited function and the generic placeholder is not preceded by a structural modifier. Such claim limitation(s) is/are: “a compiling system …” in claim 8, “a distribution system …” in claim 8, “a storage system …” in claim 8, and “a zk-SNARK setup system …” in claim 9.
Because this/these claim limitation(s) is/are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, it/they is/are being interpreted to cover the corresponding structure described in the specification as performing the claimed function, and equivalents thereof.
If applicant does not intend to have this/these limitation(s) interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, applicant may: (1) amend the claim limitation(s) to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph (e.g., by reciting sufficient structure to perform the claimed function); or (2) present a sufficient showing that the claim limitation(s) recite(s) sufficient structure to perform the claimed function so as to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph.
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.
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.
Claims 1 and 3-4 are rejected under 35 U.S.C. 103 as being unpatentable over MOREY et al. (EP 3476092 B1; hereinafter “MOREY”) in view of Nishijima (US PGPub No. 2018/0271474; hereinafter “Nishijima”) in view of Falco et al. (US PGPub No. 2020/0014531; hereinafter “Falco”) in view of KRUEGER et al. (US PGPub No. 2020/0380475; hereinafter “KRUEGER”) in view of WHITCOMB (US PGPub No. 2020/0351099; hereinafter “WHITCOMB”) in view of WANG et al. (WO 2022/0259612; hereinafter “WANG”, citations refer to the English translation).
As per claim 1: MOREY discloses a verification system comprising:
a user interface that is configured to receive a verification request from a user (The web application may send the image to an image validation system, such as by calling a web-based Application Program Interface (API) associated with the image validation system [¶ 0007]; For instance, a customer support agent may access a web application via a host computing device and submit an image provided to them from a customer [¶ 0007]; In other examples, the user may submit the image directly (e.g., in a self-service example) [¶ 0007]),
wherein the verification request comprises an identification of an image and [an imaging facility] (The image validation system may receive the image for verification and perform a multi-factor analysis on the image using various modification/tampering indicators to determine a likelihood that the image (and/or the subject depicted in the image) has been modified from its original form [¶ 0007]),
wherein the verification request comprises a user request (The image validation system may receive the image for verification and perform a multi-factor analysis on the image using various modification/tampering indicators to determine a likelihood that the image (and/or the subject depicted in the image) has been modified from its original form [¶ 0007]) [to verify that the imaging facility had used an up-to-date security configuration of imaging software when the image was produced],
[wherein a provider of the imaging software provides a record of timestamps of releases of each of a plurality of security configurations of the imaging software in a blockchain],
a verification processor that is configured to (As shown in FIG. 2, image validation service 200 may include one or more processors 202 coupled to computer-readable media 204, such as by a communication bus. The processor(s) 202 may include a central processing unit (CPU), graphics processing unit (GPU), a microprocessor, and so on [¶ 0027]):
[request a proof from] [the imaging facility] [that the security configuration of the imaging software was up-to-date when the image was produced],
[verify, based on the proof], [whether or not the security configuration of the imaging software at the imaging facility was up-to-date when the image was produced],
notify the user of the verification (For example, if tampering has been detected, an automated process may be usd to notify the customer that the image is not accepted or has been flagged for fraud and reject the request for support or concessions [¶ 0017]).
MOREY discloses the claimed subject matter as discussed above but does not explicitly disclose an imaging facility; the imaging facility. However, Nishijima teaches an imaging facility (The solutions for the problems are, for example, advice based on the results of the statistical analysis, an exemplification and proposal of the parameters on image capturing and image processing, a modification of the facility wireless network environment, a modification of wireless network parameters of the device, a modification of the settings of the medical imaging device, an addition of the optional software, an update of the software version, an application of the OS patch, as shown in FIG. 6. The analyzing device 10 of the data center D is to feedback to the client the analysis results and the solutions for the problems in the operation [¶ 0046]; The facility A can apply the analysis results and the solutions for the problems in the operation, namely a modification of the settings, a modification of parameters, a software update, and so forth, to the medical imaging devices 1, 3, 5 with or without a check by the client, in addition to the methods described above where the modification of the settings, the modification of parameters, the update of software version and such like in the medical imaging device are displayed on the screen of the device in the facility [¶ 0056]; The configurations described above can optimize the medical imaging devices 1, 3, 5, with the settings being automatically modified, the parameters being modified to be appropriate, or the software version being updated. Consequently the analyzing device 10 of the data center D can optimize the operation of the medical imaging devices 1,3, 5 without visits of the service personnel to the facilities concerned by monitoring the status and operation of the medical imaging devices 1, 3, 5 of the facility A of the client [¶ 0057]; In a case where images are captured in an X-ray room Ra of a facility such as a hospital [¶ 0026, ¶ 0034]); the imaging facility (The solutions for the problems are, for example, advice based on the results of the statistical analysis, an exemplification and proposal of the parameters on image capturing and image processing, a modification of the facility wireless network environment, a modification of wireless network parameters of the device, a modification of the settings of the medical imaging device, an addition of the optional software, an update of the software version, an application of the OS patch, as shown in FIG. 6. The analyzing device 10 of the data center D is to feedback to the client the analysis results and the solutions for the problems in the operation [¶ 0046]; The facility A can apply the analysis results and the solutions for the problems in the operation, namely a modification of the settings, a modification of parameters, a software update, and so forth, to the medical imaging devices 1, 3, 5 with or without a check by the client, in addition to the methods described above where the modification of the settings, the modification of parameters, the update of software version and such like in the medical imaging device are displayed on the screen of the device in the facility [¶ 0056]; The configurations described above can optimize the medical imaging devices 1, 3, 5, with the settings being automatically modified, the parameters being modified to be appropriate, or the software version being updated. Consequently the analyzing device 10 of the data center D can optimize the operation of the medical imaging devices 1,3, 5 without visits of the service personnel to the facilities concerned by monitoring the status and operation of the medical imaging devices 1, 3, 5 of the facility A of the client [¶ 0057]; In a case where images are captured in an X-ray room Ra of a facility such as a hospital [¶ 0026, ¶ 0034]). MOREY and Nishijima are analogous art because they are from the same field of endeavor of image security. Therefore, based on MOREY in view of Nishijima, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to utilize the teaching of Nishijima to the system of MOREY in order to automatically analyze and update software of the medical imaging device for optimizing the device. Hence, it would have been obvious to combine the references above to obtain the invention as specified in the instant claim.
MOREY in view of Nishijima discloses the claimed subject matter as discussed above but does not explicitly disclose an up-to-date security configuration of imaging software; that the security configuration of the imaging software was up-to-date when the image was produced; whether or not the security configuration of the imaging software at the imaging facility was up-to-date when the image was produced. However, Falco teaches an up-to-date security configuration of imaging software when the image was produced (In one aspect, the first Internet-connected device includes at least one of: a sensor, a meter, a regulator, an actuator, a scanner, an image or video acquisition device, a biometric reader, and a card reader. In one aspect, the first Internet-connected device includes at least one of: a sensor, a meter, a regulator, an actuator, a scanner, an image or video acquisition device, a biometric reader, and a card reader. In one aspect, the first device node includes one of: a medical device, a camera, a smart home device, a closed circuit TV/security device, a portable media player, an electronic bracelet, a smart watch, an electric utility device, a water network device, a transportation system device, an oil refinery device, a chemical/manufacturing plant device, an assembly line device, and a mining operation device [¶ 0012]; In one aspect, the at least one first node command and/or the at least one first node parameter included in the at least one of the first blockchain transactions constitutes at least one security update for the first device node. The at least one device management process performed by the first device node includes at least one device security process, and upon execution of the device management firmware, the processor of the first device node can control the communication interface to receive, via the Internet, the at least one security update for the first device node included in the at least one of the first blockchain transactions, and implement the at least one device security process to control the first device node based at least in part on the received at least one security update [¶ 0013]; Upon execution of the device management firmware, the processor of the first Internet-connected device: controls the communication interface to receive, via the Internet, the at least one security update for the first Internet-connected device; and implements the at least one device security process to control the first Internet-connected device based at least in part on the received at least one security update [¶ 0036]); that the security configuration of the imaging software was up-to-date when the image was produced (In one aspect, the first Internet-connected device includes at least one of: a sensor, a meter, a regulator, an actuator, a scanner, an image or video acquisition device, a biometric reader, and a card reader. In one aspect, the first Internet-connected device includes at least one of: a sensor, a meter, a regulator, an actuator, a scanner, an image or video acquisition device, a biometric reader, and a card reader. In one aspect, the first device node includes one of: a medical device, a camera, a smart home device, a closed circuit TV/security device, a portable media player, an electronic bracelet, a smart watch, an electric utility device, a water network device, a transportation system device, an oil refinery device, a chemical/manufacturing plant device, an assembly line device, and a mining operation device [¶ 0012]; In one aspect, the at least one first node command and/or the at least one first node parameter included in the at least one of the first blockchain transactions constitutes at least one security update for the first device node. The at least one device management process performed by the first device node includes at least one device security process, and upon execution of the device management firmware, the processor of the first device node can control the communication interface to receive, via the Internet, the at least one security update for the first device node included in the at least one of the first blockchain transactions, and implement the at least one device security process to control the first device node based at least in part on the received at least one security update [¶ 0013]; Upon execution of the device management firmware, the processor of the first Internet-connected device: controls the communication interface to receive, via the Internet, the at least one security update for the first Internet-connected device; and implements the at least one device security process to control the first Internet-connected device based at least in part on the received at least one security update [¶ 0036]); whether or not the security configuration of the imaging software at the imaging facility was up-to-date when the image was produced (In one aspect, the first Internet-connected device includes at least one of: a sensor, a meter, a regulator, an actuator, a scanner, an image or video acquisition device, a biometric reader, and a card reader. In one aspect, the first Internet-connected device includes at least one of: a sensor, a meter, a regulator, an actuator, a scanner, an image or video acquisition device, a biometric reader, and a card reader. In one aspect, the first device node includes one of: a medical device, a camera, a smart home device, a closed circuit TV/security device, a portable media player, an electronic bracelet, a smart watch, an electric utility device, a water network device, a transportation system device, an oil refinery device, a chemical/manufacturing plant device, an assembly line device, and a mining operation device [¶ 0012]; In one aspect, the at least one first node command and/or the at least one first node parameter included in the at least one of the first blockchain transactions constitutes at least one security update for the first device node. The at least one device management process performed by the first device node includes at least one device security process, and upon execution of the device management firmware, the processor of the first device node can control the communication interface to receive, via the Internet, the at least one security update for the first device node included in the at least one of the first blockchain transactions, and implement the at least one device security process to control the first device node based at least in part on the received at least one security update [¶ 0013]; Upon execution of the device management firmware, the processor of the first Internet-connected device: controls the communication interface to receive, via the Internet, the at least one security update for the first Internet-connected device; and implements the at least one device security process to control the first Internet-connected device based at least in part on the received at least one security update [¶ 0036]). MOREY in view of Nishijima and Falco are analogous art because they are from the same field of endeavor of imaging security. Therefore, based on MOREY in view of Nishijima in view of Falco, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to utilize the teaching of Falco to the system of MOREY in view of Nishijima in order to enhance device security through receiving security updates from a dedicated channel. Hence, it would have been obvious to combine the references above to obtain the invention as specified in the instant claim.
MOREY in view of Nishijima in view of Falco discloses the claimed subject matter as discussed above but does not explicitly disclose to verify that the facility. However, KRUEGER teaches verify that the facility (A medical institution may be a hospital, a medical research facility, a medical practice, a outpatient department, a certain part of a hospital, a company developing and/or producing medical apparatuses and/or parts of medical apparatuses, or any group comprising one or several of the mentioned examples. A medical institution may also be any other institution in the medical context [¶ 0086]; According to a further embodiment of the invention the medical data record comprises a medical image, wherein the modified medical data record comprises the medical image equipped with a watermark, and wherein the watermark comprises the identifier of the second entity. In other words, the modified data record comprises a modified medical image, wherein the modified medical image is the medical image equipped with a watermark. In other words, the modified medical image comprises information of the medical image and in formation of the watermark [¶ 0312]). MOREY in view of Nishijima in view of Falco and KRUEGER are analogous art because they are from the same field of endeavor of image security. Therefore, based on MOREY in view of Nishijima in view of Falco in view of KRUEGER, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to utilize the teaching of KRUEGER to the system of MOREY in view of Nishijima in view of Falco in order to improve data protection. Hence, it would have been obvious to combine the references above to obtain the invention as specified in the instant claim.
MOREY in view of Nishijima in view of Falco in view of KRUEGER discloses the claimed subject matter as discussed above but does not explicitly disclose wherein a provider of the imaging software provides a record of timestamps of releases of each of a plurality of security configurations of the imaging software in a blockchain. However, WHITCOMB teaches wherein a provider of the imaging software provides a record of timestamps of releases of each of a plurality of security configurations of the imaging software in a blockchain (Embodiments described herein may be configured to provide and maintain irrefutable proof of when, what, where and by whom transactions/activities related to the building, testing, deployment and release of a software product were performed. In addition, the disclosed embodiments may be configured to provide, via an immutable electronic ledger that may be inspected by auditors and compliance organizations, an audit trail of the transactions/activities associated with the software product, what the transactions/activities were, when they were made and by whom [¶ 0007]; FIG. 6 shows an example software release cycle pipeline of services 600, and example software services 620, 630, 640, 650 associated with the software release cycle, according to an embodiment of the present disclosure. For example, the pipeline 600 may include build services 620, test and quality services 630, deployment services 640 and release services 650. As shown in the example embodiment, the build services 620, test and quality services 630, deployment services 640 and release services 650 each have access to the same electronic ledger 610, which in the illustrated example is implemented using blockchain technology as discussed above [¶ 0059]; Once validated, the electronic ledger is updated at step 508. In accordance with the disclosed principles, the ledger may be updated by adding a new block and the contents of the transaction/activity discussed above ( e.g., initial SHA identifier of the source code from the Git repository; secure hash of the build artifact; location of the artifact; timestamp of the start and end of each transaction; unique identifier of the build, deploy and release requester; secure hashes of intermediate listings of build and deployment specifics and the locations of the listings) [¶ 0056]; The type of data that may be managed in the blocks 412, 414, 416, 418, 420 within the ledger 410 could be: The initial SHA (secure hash algorithm) identifier of the source code from the Git repository. The secure hash of the build artifact. The location of the artifact. The timestamp of the start and end of each transaction. The unique identifier of the build, deploy and release requester. Secure hashes of intermediate listings of build and deployment specifics and the locations of the listings [¶ 0047-0053]). MOREY in view of Nishijima in view of Falco in view of KRUEGER and WHITCOMB are analogous art because they are from the same field of endeavor of image security. Therefore, based on MOREY in view of Nishijima in view of Falco in view of KRUEGER in view of WHITCOMB, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to utilize the teaching of WHITCOMB to the system of MOREY in view of Nishijima in view of Falco in view of KRUEGER in order to efficiently store data in an immutable and verifiable manner. Hence, it would have been obvious to combine the references above to obtain the invention as specified in the instant claim.
MOREY in view of Nishijima in view of Falco in view of KRUEGER in view of WHITCOMB discloses the claimed subject matter as discussed above but does not explicitly disclose request a proof from; verify, based on the proof. However, WANG teaches request a proof from (The accident trigger generator 411 performs an accident detection process, and when an accident is detected, transmits a request trigger to the camera 412 present in the surroundings to request position proof [Page 29, para. 4]; The watermark superimposing unit 633 receives the secret key from the server 413 via the network 421 and the communication unit 610. The watermark superimposing unit 633 generates a watermark using the secret key and superimposes the watermark on the image data supplied from the camera 412. The watermark superimposing unit 633 associates the watermark-superimposed image data with position information indicating the shooting position of the image data and stores them in the storage 60 [Page 31, para. 3]); verify, based on the proof (The location verification unit 732 verifies the watermark superimposed on the image data included in the location certification information received from the camera 412, and also verifies the image data accumulated in the image DB 704 and the image data included in the location certification information. The position information included in the position proof information is verified by comparing with. The position verification section 732 includes a private key generation section 741, a watermark extraction section 742, a watermark verification section 743, a feature extraction section 744 and a feature verification section 745 [Page 31, last para.; Page 32, first para.]). MOREY in view of Nishijima in view of Falco in view of KRUEGER in view of WHITCOMB and WANG are analogous art because they are from the same field of endeavor of image security. Therefore, based on MOREY in view of Nishijima in view of Falco in view of KRUEGER in view of WHITCOMB in view of WANG, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to utilize the teaching of WANG to the system of MOREY in view of Nishijima in view of Falco in view of KRUEGER in view of WHITCOMB in order to effectively verify through proof the location an image was created. Hence, it would have been obvious to combine the references above to obtain the invention as specified in the instant claim.
As per claim 3: MOREY in view of Nishijima in view of Falco in view of KRUEGER in view of WHITCOMB in view of WANG teach all the limitations of claim 1. Furthermore, WANG discloses wherein the identification of the image comprises a hash of the image (The image registration unit 153 calculates a hash value of the image data encrypted in step S603 [WANG, Page 26, para. 7]).
As per claim 4: MOREY in view of Nishijima in view of Falco in view of KRUEGER in view of WHITCOMB in view of WANG teach all the limitations of claim 1. Furthermore, MOREY, KRUEGER, and WANG disclose wherein the verification processor (As shown in FIG. 2, image validation service 200 may include one or more processors 202 coupled to computer-readable media 204, such as by a communication bus. The processor(s) 202 may include a central processing unit (CPU), graphics processing unit (GPU), a microprocessor, and so on [MOREY ¶ 0027]) executes a smart contract (the further data block and/or the further medical dataset comprise a smart contract [KRUEGER ¶ 0170]; In general, a smart contract comprises program elements which can be executed by the block creation unit, in particular the calculation unit of the block creation unit, or any other device. In particular, the program elements can comprise source code, scripting language and/or compiled machine code. In particular, a smart contract can be executed. In particular, a smart contract is documented in a distributed ledger, by the further data block and/or the further medical dataset being documented in the distributed ledger. In particular, a smart contract can comprise conditions in terms of program logic, and consequences in terms of program logic, wherein the consequences are activated or executed if certain conditions are fulfilled [KRUEGER ¶ 0171]) to request and verify the proof (The accident trigger generator 411 performs an accident detection process, and when an accident is detected, transmits a request trigger to the camera 412 present in the surroundings to request position proof [WANG, Page 29, para. 4]; The location verification unit 732 verifies the watermark superimposed on the image data included in the location certification information received from the camera 412, and also verifies the image data accumulated in the image DB 704 and the image data included in the location certification information. The position information included in the position proof information is verified by comparing with. The position verification section 732 includes a private key generation section 741, a watermark extraction section 742, a watermark verification section 743, a feature extraction section 744 and a feature verification section 745 [WANG, Page 31, last para.; Page 32, first para.]).
Claim 2 is rejected under 35 U.S.C. 103 as being unpatentable over MOREY in view of Nishijima in view of Falco in view of KRUEGER in view of WHITCOMB in view of WANG in view of Walsh et al. (US Patent No. 12147823; hereinafter “Walsh”).
As per claim 2: MOREY in view of Nishijima in view of Falco in view of KRUEGER in view of WHITCOMB in view of WANG teach all the limitations of claim 1. Furthermore, MOREY, Nishijima, and WANG disclose wherein the verification processor (As shown in FIG. 2, image validation service 200 may include one or more processors 202 coupled to computer-readable media 204, such as by a communication bus. The processor(s) 202 may include a central processing unit (CPU), graphics processing unit (GPU), a microprocessor, and so on [MOREY ¶ 0027]) comprises [a zk-SNARK verifier and an associated verifier key provided by the providing system], wherein the proof (The watermark superimposing unit 633 receives the secret key from the server 413 via the network 421 and the communication unit 610. The watermark superimposing unit 633 generates a watermark using the secret key and superimposes the watermark on the image data supplied from the camera 412. The watermark superimposing unit 633 associates the watermark-superimposed image data with position information indicating the shooting position of the image data and stores them in the storage 60 [WANG, Page 31, para. 3]) from the imaging facility (The solutions for the problems are, for example, advice based on the results of the statistical analysis, an exemplification and proposal of the parameters on image capturing and image processing, a modification of the facility wireless network environment, a modification of wireless network parameters of the device, a modification of the settings of the medical imaging device, an addition of the optional software, an update of the software version, an application of the OS patch, as shown in FIG. 6. The analyzing device 10 of the data center D is to feedback to the client the analysis results and the solutions for the problems in the operation [Nishijima ¶ 0046]; The facility A can apply the analysis results and the solutions for the problems in the operation, namely a modification of the settings, a modification of parameters, a software update, and so forth, to the medical imaging devices 1, 3, 5 with or without a check by the client, in addition to the methods described above where the modification of the settings, the modification of parameters, the update of software version and such like in the medical imaging device are displayed on the screen of the device in the facility [Nishijima ¶ 0056]; The configurations described above can optimize the medical imaging devices 1, 3, 5, with the settings being automatically modified, the parameters being modified to be appropriate, or the software version being updated. Consequently the analyzing device 10 of the data center D can optimize the operation of the medical imaging devices 1,3, 5 without visits of the service personnel to the facilities concerned by monitoring the status and operation of the medical imaging devices 1, 3, 5 of the facility A of the client [Nishijima ¶ 0057]; In a case where images are captured in an X-ray room Ra of a facility such as a hospital [Nishijima ¶ 0026, ¶ 0034]) [is a zk-SNARK proof].
MOREY in view of Nishijima in view of Falco in view of KRUEGER in view of WHITCOMB in view of WANG discloses the claimed subject matter as discussed above but does not explicitly disclose a zk-SNARK verifier and an associated verifier key provided by the providing system; is a zk-SNARK proof. However, Walsh teaches a zk-SNARK verifier and an associated verifier key provided by the providing system (create a second partition within the virtual environment based on the configuration request by allocating processor time and a memory space for the second partition using the hypervisor based on the a partition policy, integrate a software module into the virtual environment by instantiating, within the second partition, a software image into a container having a non-preemptable container runtime, and verify a compliance of the integrated software module at the first partition [abstract]; Aspects of the present disclosure can be used to ensure compliance of software applications with stringent safety standards, such as those found in various avionics [Column 2, lines 65-67, Column 3, lines 1-5]; With continued reference to FIG. 1, in some cases, a zero-knowledge proof, which may provide an output demonstrating possession of a secret while revealing none of the secret to a recipient of the output; zero-knowledge proof may be information-theoretically secure, meaning that an entity with infinite computing power would be unable to determine secret from output. Alternatively, zero-knowledge proof may be computationally secure, meaning that determination of secret from output is computationally infeasible, for instance to the same extent that determination of a private key from a public key in a public key cryptographic system is computationally infeasible. Zero-knowledge proof algorithms may generally include a set of two algorithms, a prover algorithm, or “P,” which is used to prove computational integrity and/or possession of a secret, and a verifier algorithm, or “V” whereby an entity may check the validity of P. Zero-knowledge proof may include an interactive zero-knowledge proof, wherein entity verifying the proof e.g., first partition 108a must directly interact with the proving entity e.g., second partition 108b; for instance, the verifying and proving partitions may be required to be online, or connected to the same network as each other, at the same time. In a non-limiting example, this may be enabled by, at least in part, virtualization layer 114 and virtual bus 144 as described above. In some cases, interactive zero-knowledge proof may include a “proof of knowledge” proof, such as a Schnorr algorithm for proof on knowledge of a discrete logarithm. In a Schnorr algorithm, a prover commits to a randomness r, generates a message based on r, and generates a message adding r to a challenge c multiplied by a discrete logarithm that the prover is able to calculate; verification is performed by the verifier who produced c by exponentiation, thus checking the validity of the discrete logarithm. Interactive zero-knowledge proofs may alternatively or additionally include sigma protocols. Persons skilled in the art, upon reviewing the entirety of this disclosure, will be aware of various alternative interactive zero-knowledge proofs that may be implemented consistently with this disclosure [Column 24, lines 22-60]; With continued reference to FIG. 1, alternatively, zero-knowledge proof may include a non-interactive zero-knowledge, proof, or a proof wherein neither entity to the proof interacts with the other entity to the proof; for instance, first partition 108a receiving the proof and second partition 108b providing the proof may receive a reference datum which the partition providing the proof may modify or otherwise use to perform the proof. As a non-limiting example, zero-knowledge proof may include a succinct non-interactive arguments of knowledge (ZK-SNARKS) proof, wherein a “trusted setup” process creates proof and verification keys using secret (and subsequently discarded) information encoded using a public key cryptographic system, a prover runs a proving algorithm using the proving key and secret information available to the prover, and a verifier checks the proof using the verification key; public key cryptographic system may include RSA, elliptic curve cryptography, ElGamal, or any other suitable public key cryptographic system. Generation of trusted setup may be performed using a secure multiparty computation so that no one entity has control of the totality of the secret information used in the trusted setup; as a result, if any one partition generating the trusted setup is trustworthy, the secret information may be unrecoverable by malicious parties. As another non-limiting example, non-interactive zero-knowledge proof may include a Succinct Transparent Arguments of Knowledge (ZK-STARKS) zero-knowledge proof. In an embodiment, a ZK-STARKS proof includes a Merkle root of a Merkle tree representing evaluation of a secret computation at some number of points, which may be 1 billion points, plus Merkle branches representing evaluations at a set of randomly selected points of the number of points; verification may include determining that Merkle branches provided match the Merkle root, and that point verifications at those branches represent valid values, where validity is shown by demonstrating that all values belong to the same polynomial created by transforming the secret computation. In an embodiment, ZK-STARKS does not require a trusted setup. [Column 24, lines 61-67, Column 25, lines 1-31]); is a zk-SNARK proof (create a second partition within the virtual environment based on the configuration request by allocating processor time and a memory space for the second partition using the hypervisor based on the a partition policy, integrate a software module into the virtual environment by instantiating, within the second partition, a software image into a container having a non-preemptable container runtime, and verify a compliance of the integrated software module at the first partition [abstract]; Aspects of the present disclosure can be used to ensure compliance of software applications with stringent safety standards, such as those found in various avionics [Column 2, lines 65-67, Column 3, lines 1-5]; With continued reference to FIG. 1, in some cases, a zero-knowledge proof, which may provide an output demonstrating possession of a secret while revealing none of the secret to a recipient of the output; zero-knowledge proof may be information-theoretically secure, meaning that an entity with infinite computing power would be unable to determine secret from output. Alternatively, zero-knowledge proof may be computationally secure, meaning that determination of secret from output is computationally infeasible, for instance to the same extent that determination of a private key from a public key in a public key cryptographic system is computationally infeasible. Zero-knowledge proof algorithms may generally include a set of two algorithms, a prover algorithm, or “P,” which is used to prove computational integrity and/or possession of a secret, and a verifier algorithm, or “V” whereby an entity may check the validity of P. Zero-knowledge proof may include an interactive zero-knowledge proof, wherein entity verifying the proof e.g., first partition 108a must directly interact with the proving entity e.g., second partition 108b; for instance, the verifying and proving partitions may be required to be online, or connected to the same network as each other, at the same time. In a non-limiting example, this may be enabled by, at least in part, virtualization layer 114 and virtual bus 144 as described above. In some cases, interactive zero-knowledge proof may include a “proof of knowledge” proof, such as a Schnorr algorithm for proof on knowledge of a discrete logarithm. In a Schnorr algorithm, a prover commits to a randomness r, generates a message based on r, and generates a message adding r to a challenge c multiplied by a discrete logarithm that the prover is able to calculate; verification is performed by the verifier who produced c by exponentiation, thus checking the validity of the discrete logarithm. Interactive zero-knowledge proofs may alternatively or additionally include sigma protocols. Persons skilled in the art, upon reviewing the entirety of this disclosure, will be aware of various alternative interactive zero-knowledge proofs that may be implemented consistently with this disclosure [Column 24, lines 22-60]; With continued reference to FIG. 1, alternatively, zero-knowledge proof may include a non-interactive zero-knowledge, proof, or a proof wherein neither entity to the proof interacts with the other entity to the proof; for instance, first partition 108a receiving the proof and second partition 108b providing the proof may receive a reference datum which the partition providing the proof may modify or otherwise use to perform the proof. As a non-limiting example, zero-knowledge proof may include a succinct non-interactive arguments of knowledge (ZK-SNARKS) proof, wherein a “trusted setup” process creates proof and verification keys using secret (and subsequently discarded) information encoded using a public key cryptographic system, a prover runs a proving algorithm using the proving key and secret information available to the prover, and a verifier checks the proof using the verification key; public key cryptographic system may include RSA, elliptic curve cryptography, ElGamal, or any other suitable public key cryptographic system. Generation of trusted setup may be performed using a secure multiparty computation so that no one entity has control of the totality of the secret information used in the trusted setup; as a result, if any one partition generating the trusted setup is trustworthy, the secret information may be unrecoverable by malicious parties. As another non-limiting example, non-interactive zero-knowledge proof may include a Succinct Transparent Arguments of Knowledge (ZK-STARKS) zero-knowledge proof. In an embodiment, a ZK-STARKS proof includes a Merkle root of a Merkle tree representing evaluation of a secret computation at some number of points, which may be 1 billion points, plus Merkle branches representing evaluations at a set of randomly selected points of the number of points; verification may include determining that Merkle branches provided match the Merkle root, and that point verifications at those branches represent valid values, where validity is shown by demonstrating that all values belong to the same polynomial created by transforming the secret computation. In an embodiment, ZK-STARKS does not require a trusted setup. [Column 24, lines 61-67, Column 25, lines 1-31]). Walsh and the instant application are analogous art because they are from the same field of endeavor of zk-snarks proofs. Therefore, based on MOREY in view of Nishijima in view of Falco in view of KRUEGER in view of WHITCOMB in view of WANG in view of Walsh, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to utilize the teaching of Walsh to the system of MOREY in view of Nishijima in view of Falco in view of KRUEGER in view of WHITCOMB in view of WANG in order to securely establish a trusted proof through a trusted setup. Hence, it would have been obvious to combine the references above to obtain the invention as specified in the instant claim.
Claim 8 is rejected under 35 U.S.C. 103 as being unpatentable over WHITCOMB (US PGPub No. 2020/0351099; hereinafter “WHITCOMB”) in view of Falco et al. (US PGPub No. 2020/0014531; hereinafter “Falco”) in view of Nishijima (US PGPub No. 2018/0271474; hereinafter “Nishijima”).
As per claim 8: WHITCOMB discloses a system comprising (Embodiments described herein may be configured to provide and maintain irrefutable proof of when, what, where and by whom transactions/activities related to the building, testing, deployment and release of a software product were performed. In addition, the disclosed embodiments may be configured to provide, via an immutable electronic ledger that may be inspected by auditors and compliance organizations, an audit trail of the transactions/activities associated with the software product, what the transactions/activities were, when they were made and by whom [¶ 0007]):
a compiling system that produces a plurality of [security] configurations of [imaging] software over time (Cn, DTn) (FIG. 6 shows an example software release cycle pipeline of services 600, and example software services 620, 630, 640, 650 associated with the software release cycle, according to an embodiment of the present disclosure. For example, the pipeline 600 may include build services 620, test and quality services 630, deployment services 640 and release services 650. As shown in the example embodiment, the build services 620, test and quality services 630, deployment services 640 and release services 650 each have access to the same electronic ledger 610, which in the illustrated example is implemented using blockchain technology as discussed above [¶ 0059, Fig. 6]; the software release cycle flows from left to right in the pipeline 600, starting with the build services 620 and ending with the release services 650. Depending upon the complexity of the software being released, the pipeline 600 could consist of multiple test and deployment steps. The illustrated pipeline 600 consists of various build, test, deployment and release services available in the market place. It should be appreciated that any of these could be combined to construct a software release system. As such, and as explained above, it is critical to provide a way to track and audit the release process. As can be appreciated, the ledger 610 ensures the actors, artifacts and flow of the release process is what was intended. Thus, providing irrefutable proof that there were no interlopers involved in the process and that no steps were skipped [¶ 0060]; the build services 620 may include one or more of a Jenkins build system 622, Amazon Web Services (AWS) Codebuild 624, and or a Travis CI (continuous integration) service. As known in the art, Jenkins is an open source automation server, providing tools and plugins to support the building, deployment and automation of a software product. An AWS Codebuild provides for the building and testing of code in a cloud-based environment. Travis CI is a hosted, distributed continuous integration service used to build and test software projects [¶ 0061]),
a distribution system that provides each [security] configuration of the [imaging] software to at least one [imaging facility] (As shown in the illustrated example, the deployment services 640 my include one or more of AMAZON CodeDeploy 642, Bamboo 644 and or Octopus Deploy 646 services. As is known in the art, each of AMAZON CodeDeploy 642, Bamboo 644 and or Octopus Deploy 646 are services that automate software deployments to a variety of computer systems and services [¶ 0063, Fig. 6]; As shown in the illustrated example, the release services 650 my include one or more of Automic Release Automation 652, BMC Release Process Management 654 and or IBM URBANCODE RELEASE 656. As is known in the art, XXX services, among other things, manage the release of software, infrastructure changes and simultaneous deployments of multiple software products/applications [¶ 0064]), and
a storage system that stores a [security] configuration timestamp corresponding to a release of each [security] configuration of the [imaging] software to the [imaging facility] in a blockchain (FIG. 6 shows an example software release cycle pipeline of services 600, and example software services 620, 630, 640, 650 associated with the software release cycle, according to an embodiment of the present disclosure. For example, the pipeline 600 may include build services 620, test and quality services 630, deployment services 640 and release services 650. As shown in the example embodiment, the build services 620, test and quality services 630, deployment services 640 and release services 650 each have access to the same electronic ledger 610, which in the illustrated example is implemented using blockchain technology as discussed above [¶ 0059]; Once validated, the electronic ledger is updated at step 508. In accordance with the disclosed principles, the ledger may be updated by adding a new block and the contents of the transaction/activity discussed above ( e.g., initial SHA identifier of the source code from the Git repository; secure hash of the build artifact; location of the artifact; timestamp of the start and end of each transaction; unique identifier of the build, deploy and release requester; secure hashes of intermediate listings of build and deployment specifics and the locations of the listings) [¶ 0056]; The type of data that may be managed in the blocks 412, 414, 416, 418, 420 within the ledger 410 could be: The initial SHA (secure hash algorithm) identifier of the source code from the Git repository. The secure hash of the build artifact. The location of the artifact. The timestamp of the start and end of each transaction. The unique identifier of the build, deploy and release requester. Secure hashes of intermediate listings of build and deployment specifics and the locations of the listings [¶ 0047-0053]).
WHITCOMB discloses the claimed subject matter as discussed above but does not explicitly disclose security configurations of imaging software; security configuration of imaging software; a security configuration; security configurations of the imaging software. However, Falco teaches security configurations of imaging software (In one aspect, the first Internet-connected device includes at least one of: a sensor, a meter, a regulator, an actuator, a scanner, an image or video acquisition device, a biometric reader, and a card reader. In one aspect, the first Internet-connected device includes at least one of: a sensor, a meter, a regulator, an actuator, a scanner, an image or video acquisition device, a biometric reader, and a card reader. In one aspect, the first device node includes one of: a medical device, a camera, a smart home device, a closed circuit TV/security device, a portable media player, an electronic bracelet, a smart watch, an electric utility device, a water network device, a transportation system device, an oil refinery device, a chemical/manufacturing plant device, an assembly line device, and a mining operation device [¶ 0012]; In one aspect, the at least one first node command and/or the at least one first node parameter included in the at least one of the first blockchain transactions constitutes at least one security update for the first device node. The at least one device management process performed by the first device node includes at least one device security process, and upon execution of the device management firmware, the processor of the first device node can control the communication interface to receive, via the Internet, the at least one security update for the first device node included in the at least one of the first blockchain transactions, and implement the at least one device security process to control the first device node based at least in part on the received at least one security update [¶ 0013]); security configuration of imaging software (In one aspect, the first Internet-connected device includes at least one of: a sensor, a meter, a regulator, an actuator, a scanner, an image or video acquisition device, a biometric reader, and a card reader. In one aspect, the first Internet-connected device includes at least one of: a sensor, a meter, a regulator, an actuator, a scanner, an image or video acquisition device, a biometric reader, and a card reader. In one aspect, the first device node includes one of: a medical device, a camera, a smart home device, a closed circuit TV/security device, a portable media player, an electronic bracelet, a smart watch, an electric utility device, a water network device, a transportation system device, an oil refinery device, a chemical/manufacturing plant device, an assembly line device, and a mining operation device [¶ 0012]; In one aspect, the at least one first node command and/or the at least one first node parameter included in the at least one of the first blockchain transactions constitutes at least one security update for the first device node. The at least one device management process performed by the first device node includes at least one device security process, and upon execution of the device management firmware, the processor of the first device node can control the communication interface to receive, via the Internet, the at least one security update for the first device node included in the at least one of the first blockchain transactions, and implement the at least one device security process to control the first device node based at least in part on the received at least one security update [¶ 0013]); a security configuration (In one aspect, the at least one first node command and/or the at least one first node parameter included in the at least one of the first blockchain transactions constitutes at least one security update for the first device node. The at least one device management process performed by the first device node includes at least one device security process, and upon execution of the device management firmware, the processor of the first device node can control the communication interface to receive, via the Internet, the at least one security update for the first device node included in the at least one of the first blockchain transactions, and implement the at least one device security process to control the first device node based at least in part on the received at least one security update [¶ 0013]); security configurations of the imaging software (In one aspect, the first Internet-connected device includes at least one of: a sensor, a meter, a regulator, an actuator, a scanner, an image or video acquisition device, a biometric reader, and a card reader. In one aspect, the first Internet-connected device includes at least one of: a sensor, a meter, a regulator, an actuator, a scanner, an image or video acquisition device, a biometric reader, and a card reader. In one aspect, the first device node includes one of: a medical device, a camera, a smart home device, a closed circuit TV/security device, a portable media player, an electronic bracelet, a smart watch, an electric utility device, a water network device, a transportation system device, an oil refinery device, a chemical/manufacturing plant device, an assembly line device, and a mining operation device [¶ 0012]; In one aspect, the at least one first node command and/or the at least one first node parameter included in the at least one of the first blockchain transactions constitutes at least one security update for the first device node. The at least one device management process performed by the first device node includes at least one device security process, and upon execution of the device management firmware, the processor of the first device node can control the communication interface to receive, via the Internet, the at least one security update for the first device node included in the at least one of the first blockchain transactions, and implement the at least one device security process to control the first device node based at least in part on the received at least one security update [¶ 0013]). WHITCOMB and Falco are analogous art because they are from the same field of endeavor of blockchain based security. Therefore, based on WHITCOMB in view of Falco, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to utilize the teaching of Falco to the system of WHITCOMB in order to enhance device security through receiving security updates from a dedicated channel. Hence, it would have been obvious to combine the references above to obtain the invention as specified in the instant claim.
WHITCOMB in view of Falco discloses the claimed subject matter as discussed above but does not explicitly disclose imaging facility. However, Nishijima teaches imaging facility (The solutions for the problems are, for example, advice based on the results of the statistical analysis, an exemplification and proposal of the parameters on image capturing and image processing, a modification of the facility wireless network environment, a modification of wireless network parameters of the device, a modification of the settings of the medical imaging device, an addition of the optional software, an update of the software version, an application of the OS patch, as shown in FIG. 6. The analyzing device 10 of the data center D is to feedback to the client the analysis results and the solutions for the problems in the operation [¶ 0046]; The facility A can apply the analysis results and the solutions for the problems in the operation, namely a modification of the settings, a modification of parameters, a software update, and so forth, to the medical imaging devices 1, 3, 5 with or without a check by the client, in addition to the methods described above where the modification of the settings, the modification of parameters, the update of software version and such like in the medical imaging device are displayed on the screen of the device in the facility [¶ 0056]; The configurations described above can optimize the medical imaging devices 1, 3, 5, with the settings being automatically modified, the parameters being modified to be appropriate, or the software version being updated. Consequently the analyzing device 10 of the data center D can optimize the operation of the medical imaging devices 1,3, 5 without visits of the service personnel to the facilities concerned by monitoring the status and operation of the medical imaging devices 1, 3, 5 of the facility A of the client [¶ 0057]; In a case where images are captured in an X-ray room Ra of a facility such as a hospital [¶ 0026, ¶ 0034]). Nishijima and the instant application are analogous art because they are from the same field of endeavor of medical device improvement. Therefore, based on WHITCOMB in view of Falco in view of Nishijima, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to utilize the teaching of Nishijima to the system of WHITCOMB in view of Falco in order to automatically analyze and update software of the medical imaging device for optimizing the device. Hence, it would have been obvious to combine the references above to obtain the invention as specified in the instant claim.
Claim 9 is rejected under 35 U.S.C. 103 as being unpatentable over WHITCOMB in view of Falco in view of Nishijima in view of Walsh.
As per claim 9: WHITCOMB in view of Falco in view of Nishijima teach all the limitations of claim 8. Furthermore, Falco and Nishijima disclose comprising: [a zk-SNARK setup system that processes a security configuration verification algorithm and generates a zk-SNARK prover, a zk-SNARK prover key, a zk-SNARK verifier, and a zk-SNARK verifier key, wherein the zk-SNARK prover and zk-SNARK prover key is provided] to the imaging facility (The solutions for the problems are, for example, advice based on the results of the statistical analysis, an exemplification and proposal of the parameters on image capturing and image processing, a modification of the facility wireless network environment, a modification of wireless network parameters of the device, a modification of the settings of the medical imaging device, an addition of the optional software, an update of the software version, an application of the OS patch, as shown in FIG. 6. The analyzing device 10 of the data center D is to feedback to the client the analysis results and the solutions for the problems in the operation [¶ 0046]; The facility A can apply the analysis results and the solutions for the problems in the operation, namely a modification of the settings, a modification of parameters, a software update, and so forth, to the medical imaging devices 1, 3, 5 with or without a check by the client, in addition to the methods described above where the modification of the settings, the modification of parameters, the update of software version and such like in the medical imaging device are displayed on the screen of the device in the facility [¶ 0056]; The configurations described above can optimize the medical imaging devices 1, 3, 5, with the settings being automatically modified, the parameters being modified to be appropriate, or the software version being updated. Consequently the analyzing device 10 of the data center D can optimize the operation of the medical imaging devices 1,3, 5 without visits of the service personnel to the facilities concerned by monitoring the status and operation of the medical imaging devices 1, 3, 5 of the facility A of the client [¶ 0057]; In a case where images are captured in an X-ray room Ra of a facility such as a hospital [¶ 0026, ¶ 0034]) to [provide a proof] that the security configuration of the imaging software was up-to-date when a particular image was produced (In one aspect, the first Internet-connected device includes at least one of: a sensor, a meter, a regulator, an actuator, a scanner, an image or video acquisition device, a biometric reader, and a card reader. In one aspect, the first Internet-connected device includes at least one of: a sensor, a meter, a regulator, an actuator, a scanner, an image or video acquisition device, a biometric reader, and a card reader. In one aspect, the first device node includes one of: a medical device, a camera, a smart home device, a closed circuit TV/security device, a portable media player, an electronic bracelet, a smart watch, an electric utility device, a water network device, a transportation system device, an oil refinery device, a chemical/manufacturing plant device, an assembly line device, and a mining operation device [¶ 0012]; In one aspect, the at least one first node command and/or the at least one first node parameter included in the at least one of the first blockchain transactions constitutes at least one security update for the first device node. The at least one device management process performed by the first device node includes at least one device security process, and upon execution of the device management firmware, the processor of the first device node can control the communication interface to receive, via the Internet, the at least one security update for the first device node included in the at least one of the first blockchain transactions, and implement the at least one device security process to control the first device node based at least in part on the received at least one security update [¶ 0013]; Upon execution of the device management firmware, the processor of the first Internet-connected device: controls the communication interface to receive, via the Internet, the at least one security update for the first Internet-connected device; and implements the at least one device security process to control the first Internet-connected device based at least in part on the received at least one security update [¶ 0036]), and wherein [the zk-SNARK verifier and zk-SNARK verifier key is provided to a verification system that verifies the proof provided] by the imaging facility (The solutions for the problems are, for example, advice based on the results of the statistical analysis, an exemplification and proposal of the parameters on image capturing and image processing, a modification of the facility wireless network environment, a modification of wireless network parameters of the device, a modification of the settings of the medical imaging device, an addition of the optional software, an update of the software version, an application of the OS patch, as shown in FIG. 6. The analyzing device 10 of the data center D is to feedback to the client the analysis results and the solutions for the problems in the operation [¶ 0046]; The facility A can apply the analysis results and the solutions for the problems in the operation, namely a modification of the settings, a modification of parameters, a software update, and so forth, to the medical imaging devices 1, 3, 5 with or without a check by the client, in addition to the methods described above where the modification of the settings, the modification of parameters, the update of software version and such like in the medical imaging device are displayed on the screen of the device in the facility [¶ 0056]; The configurations described above can optimize the medical imaging devices 1, 3, 5, with the settings being automatically modified, the parameters being modified to be appropriate, or the software version being updated. Consequently the analyzing device 10 of the data center D can optimize the operation of the medical imaging devices 1,3, 5 without visits of the service personnel to the facilities concerned by monitoring the status and operation of the medical imaging devices 1, 3, 5 of the facility A of the client [¶ 0057]; In a case where images are captured in an X-ray room Ra of a facility such as a hospital [¶ 0026, ¶ 0034]).
WHITCOMB in view of Falco in view of Nishijima discloses the claimed subject matter as discussed above but does not explicitly disclose a zk-SNARK setup system that processes a security configuration verification algorithm and generates a zk-SNARK prover, a zk-SNARK prover key, a zk-SNARK verifier, and a zk-SNARK verifier key, wherein the zk-SNARK prover and zk-SNARK prover key is provided; provide a proof; the zk-SNARK verifier and zk-SNARK verifier key is provided to a verification system that verifies the proof provided. However, Walsh teaches a zk-SNARK setup system that processes a security configuration verification algorithm and generates a zk-SNARK prover, a zk-SNARK prover key, a zk-SNARK verifier, and a zk-SNARK verifier key, wherein the zk-SNARK prover and zk-SNARK prover key is provided; provide a proof; the zk-SNARK verifier and zk-SNARK verifier key is provided to a verification system that verifies the proof provided (create a second partition within the virtual environment based on the configuration request by allocating processor time and a memory space for the second partition using the hypervisor based on the a partition policy, integrate a software module into the virtual environment by instantiating, within the second partition, a software image into a container having a non-preemptable container runtime, and verify a compliance of the integrated software module at the first partition [abstract]; Aspects of the present disclosure can be used to ensure compliance of software applications with stringent safety standards, such as those found in various avionics [Column 2, lines 65-67, Column 3, lines 1-5]; With continued reference to FIG. 1, in some cases, a zero-knowledge proof, which may provide an output demonstrating possession of a secret while revealing none of the secret to a recipient of the output; zero-knowledge proof may be information-theoretically secure, meaning that an entity with infinite computing power would be unable to determine secret from output. Alternatively, zero-knowledge proof may be computationally secure, meaning that determination of secret from output is computationally infeasible, for instance to the same extent that determination of a private key from a public key in a public key cryptographic system is computationally infeasible. Zero-knowledge proof algorithms may generally include a set of two algorithms, a prover algorithm, or “P,” which is used to prove computational integrity and/or possession of a secret, and a verifier algorithm, or “V” whereby an entity may check the validity of P. Zero-knowledge proof may include an interactive zero-knowledge proof, wherein entity verifying the proof e.g., first partition 108a must directly interact with the proving entity e.g., second partition 108b; for instance, the verifying and proving partitions may be required to be online, or connected to the same network as each other, at the same time. In a non-limiting example, this may be enabled by, at least in part, virtualization layer 114 and virtual bus 144 as described above. In some cases, interactive zero-knowledge proof may include a “proof of knowledge” proof, such as a Schnorr algorithm for proof on knowledge of a discrete logarithm. In a Schnorr algorithm, a prover commits to a randomness r, generates a message based on r, and generates a message adding r to a challenge c multiplied by a discrete logarithm that the prover is able to calculate; verification is performed by the verifier who produced c by exponentiation, thus checking the validity of the discrete logarithm. Interactive zero-knowledge proofs may alternatively or additionally include sigma protocols. Persons skilled in the art, upon reviewing the entirety of this disclosure, will be aware of various alternative interactive zero-knowledge proofs that may be implemented consistently with this disclosure [Column 24, lines 22-60]; With continued reference to FIG. 1, alternatively, zero-knowledge proof may include a non-interactive zero-knowledge, proof, or a proof wherein neither entity to the proof interacts with the other entity to the proof; for instance, first partition 108a receiving the proof and second partition 108b providing the proof may receive a reference datum which the partition providing the proof may modify or otherwise use to perform the proof. As a non-limiting example, zero-knowledge proof may include a succinct non-interactive arguments of knowledge (ZK-SNARKS) proof, wherein a “trusted setup” process creates proof and verification keys using secret (and subsequently discarded) information encoded using a public key cryptographic system, a prover runs a proving algorithm using the proving key and secret information available to the prover, and a verifier checks the proof using the verification key; public key cryptographic system may include RSA, elliptic curve cryptography, ElGamal, or any other suitable public key cryptographic system. Generation of trusted setup may be performed using a secure multiparty computation so that no one entity has control of the totality of the secret information used in the trusted setup; as a result, if any one partition generating the trusted setup is trustworthy, the secret information may be unrecoverable by malicious parties. As another non-limiting example, non-interactive zero-knowledge proof may include a Succinct Transparent Arguments of Knowledge (ZK-STARKS) zero-knowledge proof. In an embodiment, a ZK-STARKS proof includes a Merkle root of a Merkle tree representing evaluation of a secret computation at some number of points, which may be 1 billion points, plus Merkle branches representing evaluations at a set of randomly selected points of the number of points; verification may include determining that Merkle branches provided match the Merkle root, and that point verifications at those branches represent valid values, where validity is shown by demonstrating that all values belong to the same polynomial created by transforming the secret computation. In an embodiment, ZK-STARKS does not require a trusted setup. [Column 24, lines 61-67, Column 25, lines 1-31]). Walsh and the instant application are analogous art because they are from the same field of endeavor of zk-snarks proofs. Therefore, based on WHITCOMB in view of Falco in view of Nishijima in view of Walsh, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to utilize the teaching of Walsh to the system of WHITCOMB in view of Falco in view of Nishijima in order to securely establish a trusted proof through a trusted setup. Hence, it would have been obvious to combine the references above to obtain the invention as specified in the instant claim.
Claim 10 is rejected under 35 U.S.C. 103 as being unpatentable over WHITCOMB in view of Falco in view of Nishijima in view of Walsh in view of KRUEGER et al. (US PGPub No. 2020/0380475; hereinafter “KRUEGER”).
As per claim 10: WHITCOMB in view of Falco in view of Nishijima in view of Walsh teach all the limitations of claim 9. Furthermore, wherein the system provides [a smart contract] to the verification system to facilitate verification (The accident trigger generator 411 performs an accident detection process, and when an accident is detected, transmits a request trigger to the camera 412 present in the surroundings to request position proof [WANG, Page 29, para. 4]; The location verification unit 732 verifies the watermark superimposed on the image data included in the location certification information received from the camera 412, and also verifies the image data accumulated in the image DB 704 and the image data included in the location certification information. The position information included in the position proof information is verified by comparing with. The position verification section 732 includes a private key generation section 741, a watermark extraction section 742, a watermark verification section 743, a feature extraction section 744 and a feature verification section 745 [WANG, Page 31, last para.; Page 32, first para.]) that the security configuration of imaging software at the imaging facility was up-to-date when the particular image was produced (In one aspect, the first Internet-connected device includes at least one of: a sensor, a meter, a regulator, an actuator, a scanner, an image or video acquisition device, a biometric reader, and a card reader. In one aspect, the first Internet-connected device includes at least one of: a sensor, a meter, a regulator, an actuator, a scanner, an image or video acquisition device, a biometric reader, and a card reader. In one aspect, the first device node includes one of: a medical device, a camera, a smart home device, a closed circuit TV/security device, a portable media player, an electronic bracelet, a smart watch, an electric utility device, a water network device, a transportation system device, an oil refinery device, a chemical/manufacturing plant device, an assembly line device, and a mining operation device [¶ 0012]; In one aspect, the at least one first node command and/or the at least one first node parameter included in the at least one of the first blockchain transactions constitutes at least one security update for the first device node. The at least one device management process performed by the first device node includes at least one device security process, and upon execution of the device management firmware, the processor of the first device node can control the communication interface to receive, via the Internet, the at least one security update for the first device node included in the at least one of the first blockchain transactions, and implement the at least one device security process to control the first device node based at least in part on the received at least one security update [¶ 0013]; Upon execution of the device management firmware, the processor of the first Internet-connected device: controls the communication interface to receive, via the Internet, the at least one security update for the first Internet-connected device; and implements the at least one device security process to control the first Internet-connected device based at least in part on the received at least one security update [¶ 0036]).
WHITCOMB in view of Falco in view of Nishijima in view of Walsh discloses the claimed subject matter as discussed above but does not explicitly disclose a smart contract. However, KRUEGER teaches a smart contract (the further data block and/or the further medical dataset comprise a smart contract [KRUEGER ¶ 0170]; In general, a smart contract comprises program elements which can be executed by the block creation unit, in particular the calculation unit of the block creation unit, or any other device. In particular, the program elements can comprise source code, scripting language and/or compiled machine code. In particular, a smart contract can be executed. In particular, a smart contract is documented in a distributed ledger, by the further data block and/or the further medical dataset being documented in the distributed ledger. In particular, a smart contract can comprise conditions in terms of program logic, and consequences in terms of program logic, wherein the consequences are activated or executed if certain conditions are fulfilled [KRUEGER ¶ 0171]). KRUEGER and the instant application are analogous art because they are from the same field of endeavor of image security. Therefore, based on WHITCOMB in view of Falco in view of Nishijima in view of Walsh in view of KRUEGER, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to utilize the teaching of KRUEGER to the system of WHITCOMB in view of Falco in view of Nishijima in view of Walsh in order to improve data protection through automated operation of the verification. Hence, it would have been obvious to combine the references above to obtain the invention as specified in the instant claim.
Allowable Subject Matter
Claims 5-7 are allowed.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JAMES P MOLES whose telephone number is (703)756-1043. The examiner can normally be reached M-F 8:00am-5:00pm.
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, Jung Kim can be reached at (571) 272-3804. 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.
/JAMES P MOLES/Examiner, Art Unit 2494
/JUNG W KIM/Supervisory Patent Examiner, Art Unit 2494
Prosecution Insights