Detailed Action
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA . This is the initial office action based on the application filed on March 19th, 2024, which claim 1-20 have been presented for examination.
Status of Claims
Claims 1-20 are pending in the application, of which claims 1, 7 and 12 are in independent form and these claims (1-20) are subject to following rejection(s) and/or objection(s) set forth in the following Office Action below.
Specification
The specification is objected to as failing to provide proper antecedent basis for the claimed subject matter. See 37 CFR 1.75(d)(1) and MPEP § 608.01(o). Correction of the following is required: “one or more processing units” in claim 12 should be amended or added to the specification.
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.
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: “one or more processing unit” in claim 12.
Because this claim limitation is 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 § 112
The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. 112:
The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor of carrying out his invention.
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 12-20 are rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the written description requirement. The claim(s) contains subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for applications subject to pre-AIA 35 U.S.C. 112, the inventor(s), at the time the application was filed, had possession of the claimed invention.
Regarding claim 12: the specification does not disclose equivalent structures for the term interpreted under 112(f) above. Thus, the written description fails to disclose the corresponding structure, material, or acts for performing the entire claimed function and to clearly link the structure, material, or acts to the function.
Claims 11-20 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 pre-AIA the applicant regards as the invention.
Regarding claim 12: the specification does not disclose equivalent structures for the term interpreted under 112(f) above. Thus, claims are vague and indefinite.
Claims 13-20 depend on the rejected claims and have the same 112(a)/(b) issue.
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 of this title, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1-3 and 12-14 are rejected under 35 U.S.C. 103 as being unpatentable over Scheinkman et al. (US 2022/0058011 A1 -herein after Scheinkman) in view of Vincent Batts (US 2020/0065409 A1 herein after Batts).
Per claim 1:
Scheinkman discloses:
A method of providing provenance information (At least see ¶[0009] -generating source-code provenance data), comprising:
receiving source code at a compiler, the source code associated with a computer program (At least see ¶[0014] - first computing system 102 can compile the first source code 132 into a first executable file for inclusion in the first container image);
acquiring provenance information indicating an identity of an entity associated with the computer program (At least see ¶[0009] provenance data provided to incorporate into source code for executable code in image file; ¶[0011] metadata provide the identifier for the source code);
compiling the source code into a binary file, wherein the compiling includes automatically adding provenance data to the binary file (At least see ¶[0002] container image as a static binary file is compiled version of a software, also see ¶[0009] - incorporate such source-code provenance data into the container image);
generating executables for the computer program based on the binary file (At least see ¶[0009] -source code generated to container image including provenance data, wherein container image is a static binary file(refer to ¶[0002])).
Scheinkman discloses the method as set forth above, but Scheinkman does not explicitly discloses: storing the provenance data in a data structure by an identification module, the identification module configured to retrieve the provenance data from the data structure based on a user request.
However, Batts discloses:
storing the provenance data in a data structure by an identification module (At least see ¶[0010] - container image (with the modified metadata file) and the provenance data can then be stored in one or more repositories), the identification module configured to retrieve the provenance data from the data structure based on a user request (At least see ¶[0010] - client device can access the metadata file's indicator to obtain the provenance data ; also see ¶[0013] - indicator may include a reference to a location from which the provenance data can be obtained. Examples of the location can include a Universal Resource Locator (URL), an Internet Protocol (IP) address, or a memory address, and FIG 3 with associated text).
It would have been obvious to one ordinary skill in the art before the effective filing date of the claimed invention to incorporate Batts into Schenkman because containers are intended to be as lightweight as possible to enable fast deployment times, container images generally only have the minimal amount of content required for container deployment; as such, extraneous content is often removed from container images to improve download and deployment speeds, and wherein provenance data can then be included in a metadata file of the container image, where the indicator can be the provenance data itself or a reference to a location from which the provenance data can be retrieved, which client device may then use the provenance data to debug, replicate, or validate the container image (please see ¶[0004] and ¶[0010]).
Per claim 2:
Scheinkman discloses:
wherein acquiring provenance information and adding the provenance data is based on a user enabling a provenance tracing option incorporated into the compiler (At least see ¶[0009] provenance data provided to incorporate into source code for executable code in image file; ¶[0014] -first computing system 102 can compile the first source code 132 into a first executable file for inclusion in the first container image).
Per claim 3:
Scheinkman discloses:
wherein the provenance data is added to the binary file as an appended provenance header (At least see ¶[0009] - incorporate such source-code provenance data into the container image, so that the provenance data travels with the container image).
Per claim 12:
Scheinkman discloses:
A system (At least see ¶[0009] - system can generate source-code provenance data that indicates a location and a commit associated with source code used to generate a piece of software incorporated into a container image) comprising:
a memory device; and one or more processing units coupled with the memory device (At least see ¶[0035] -system 300 includes a processor 302 communicatively coupled with a memory 304. In some examples, the processor 302 and the memory), the one or more processing units are configured to perform a method comprising:
receiving source code at a compiler, the source code associated with a computer program (At least see ¶[0014] - first computing system 102 can compile the first source code 132 into a first executable file for inclusion in the first container image);
acquiring provenance information indicating an identity of an entity associated with the computer program (At least see ¶[0009] provenance data provided to incorporate into source code for executable code in image file; ¶[0011] metadata provide the identifier for the source code);
compiling the source code into an binary file, wherein the compiling includes automatically adding provenance data to the binary file (At least see ¶[0002] container image as a static binary file is compiled version of a software, also see ¶[0009] - incorporate such source-code provenance data into the container image); and
generating executables for the computer program based on the binary file (At least see ¶[0009] -source code generated to container image including provenance data, wherein container image is a static binary file(refer to ¶[0002])).
Scheinkman discloses the method as set forth above, but Scheinkman does not explicitly discloses: storing the provenance data in a data structure by an identification module, the identification module configured to retrieve the provenance data from the data structure based on a user request.
However, Batts discloses:
storing the provenance data in a data structure by an identification module (At least see ¶[0010] - container image (with the modified metadata file) and the provenance data can then be stored in one or more repositories), the identification module configured to retrieve the provenance data from the data structure based on a user request (At least see ¶[0010] - client device can access the metadata file's indicator to obtain the provenance data ; also see ¶[0013] - indicator may include a reference to a location from which the provenance data can be obtained. Examples of the location can include a Universal Resource Locator (URL), an Internet Protocol (IP) address, or a memory address, and FIG 3 with associated text).
It would have been obvious to one ordinary skill in the art before the effective filing date of the claimed invention to incorporate Batts into Schenkman because containers are intended to be as lightweight as possible to enable fast deployment times, container images generally only have the minimal amount of content required for container deployment; as such, extraneous content is often removed from container images to improve download and deployment speeds, and wherein provenance data can then be included in a metadata file of the container image, where the indicator can be the provenance data itself or a reference to a location from which the provenance data can be retrieved, which client device may then use the provenance data to debug, replicate, or validate the container image (please see ¶[0004] and ¶[0010]).
Per claim 13:
Scheinkman discloses:
wherein acquiring provenance information and adding the provenance data is based on a user enabling a provenance tracing option incorporated into the compiler (At least see ¶[0009] provenance data provided to incorporate into source code for executable code in image file; ¶[0014] -first computing system 102 can compile the first source code 132 into a first executable file for inclusion in the first container image).
Per claim 14:
Scheinkman discloses:
wherein the provenance data is added to the binary file as an appended provenance header (At least see ¶[0009] - incorporate such source-code provenance data into the container image, so that the provenance data travels with the container image).
Claims 4-6 and 15-20 are rejected under 35 U.S.C. 103 as being unpatentable over Scheinkman et al. (US 2022/0058011 A1 -herein after Scheinkman) in view of Vincent Batts (US 2020/0065409 A1 herein after Batts) and further in view of Lee et al. (US 2020/0358788 A1 herein after Lee).
Per claim 4:
Scheinkman modified by Batts sufficiently discloses the method as set forth above, but Scheinkman modified by Batts does not explicitly disclose: encrypting at least a portion of the provenance data before adding the provenance data to the binary file.
However, Lee discloses:
encrypting at least a portion of the provenance data before adding the provenance data to the binary file (At least see ¶[0007] provenance information based on data stored in a storage/data structure using encryption key).
It would have been obvious to one ordinary skill in the art before the effective filing date of the claimed invention to incorporate Lee into Scheinkman modified by Batts because Lee’s teaching would provide device may send the signed data transmission to a receiving device, via one or more proxy devices; in this regards, the receiving device may verify the provenance of the data by verifying the signature, decrypting the data package and evaluating the data ID, and a receiving device may verify the provenance of data even when the data has been transferred between or processed by untrusted intermediary devices in order to proxy devices interface with the producing devices to transfer or process secured data transmissions to the receiving devices (please see ¶[0004] through ¶[0006]).
Per claim 5:
Scheinkman modified by Batts sufficiently discloses the method as set forth above, but Scheinkman modified by Batts does not explicitly disclose: wherein a first portion of the provenance data includes a public portion, and a second portion of the provenance data includes a private portion, the method further comprising encrypting the public portion using a public key.
However, Lee discloses:
wherein a first portion of the provenance data includes a public portion, and a second portion of the provenance data includes a private portion, the method further comprising encrypting the public portion using a public key (At least see ¶[0047] public portion has public key i.e. metadata, and private proton associated with private encrypted key and data identifier (ID), and so see ¶[0032] and ¶[0056]).
It would have been obvious to one ordinary skill in the art before the effective filing date of the claimed invention to incorporate Lee into Scheinkman modified by Batts because Lee’s teaching would provide device may send the signed data transmission to a receiving device, via one or more proxy devices; in this regards, the receiving device may verify the provenance of the data by verifying the signature, decrypting the data package and evaluating the data ID, and a receiving device may verify the provenance of data even when the data has been transferred between or processed by untrusted intermediary devices in order to proxy devices interface with the producing devices to transfer or process secured data transmissions to the receiving devices (please see ¶[0004] through ¶[0006]).
Per claim 6:
Lee also discloses:
encrypting the encrypted public portion and the private portion using a private key (At least see ¶[0047] public portion has public key i.e. metadata, and private proton associated with private encrypted key and data identifier (ID), and so see ¶[0032] and ¶[0056]).
It would have been obvious to one ordinary skill in the art before the effective filing date of the claimed invention to incorporate Lee into Scheinkman modified by Batts because Lee’s teaching would provide device may send the signed data transmission to a receiving device, via one or more proxy devices; in this regards, the receiving device may verify the provenance of the data by verifying the signature, decrypting the data package and evaluating the data ID, and a receiving device may verify the provenance of data even when the data has been transferred between or processed by untrusted intermediary devices in order to proxy devices interface with the producing devices to transfer or process secured data transmissions to the receiving devices (please see ¶[0004] through ¶[0006]).
Per claim 15:
Scheinkman modified by Batts sufficiently discloses the method as set forth above, but Scheinkman modified by Batts does not explicitly disclose: encrypting at least a portion of the provenance data before adding the provenance data to the binary file.
However, Lee discloses:
encrypting at least a portion of the provenance data before adding the provenance data to the binary file (At least see ¶[0007] provenance information based on data stored in a storage/data structure using encryption key).
It would have been obvious to one ordinary skill in the art before the effective filing date of the claimed invention to incorporate Lee into Scheinkman modified by Batts because Lee’s teaching would provide device may send the signed data transmission to a receiving device, via one or more proxy devices; in this regards, the receiving device may verify the provenance of the data by verifying the signature, decrypting the data package and evaluating the data ID, and a receiving device may verify the provenance of data even when the data has been transferred between or processed by untrusted intermediary devices in order to proxy devices interface with the producing devices to transfer or process secured data transmissions to the receiving devices (please see ¶[0004] through ¶[0006]).
Per claim 16:
Scheinkman modified by Batts sufficiently discloses the method as set forth above, but Scheinkman modified by Batts does not explicitly disclose: wherein a first portion of the provenance data includes a public portion, and a second portion of the provenance data includes a private portion, the method further comprising encrypting the public portion using a public key.
However, Lee discloses:
wherein a first portion of the provenance data includes a public portion, and a second portion of the provenance data includes a private portion, the method further comprising encrypting the public portion using a public key (At least see ¶[0047] public portion has public key i.e. metadata, and private proton associated with private encrypted key and data identifier (ID), and so see ¶[0032] and ¶[0056]).
It would have been obvious to one ordinary skill in the art before the effective filing date of the claimed invention to incorporate Lee into Scheinkman modified by Batts because Lee’s teaching would provide device may send the signed data transmission to a receiving device, via one or more proxy devices; in this regards, the receiving device may verify the provenance of the data by verifying the signature, decrypting the data package and evaluating the data ID, and a receiving device may verify the provenance of data even when the data has been transferred between or processed by untrusted intermediary devices in order to proxy devices interface with the producing devices to transfer or process secured data transmissions to the receiving devices (please see ¶[0004] through ¶[0006]).
Per claim 17:
Lee also discloses:
encrypting the encrypted public portion and the private portion using a private key (At least see ¶[0047] public portion has public key i.e. metadata, and private proton associated with private encrypted key and data identifier (ID), and so see ¶[0032] and ¶[0056]).
It would have been obvious to one ordinary skill in the art before the effective filing date of the claimed invention to incorporate Lee into Scheinkman modified by Batts because Lee’s teaching would provide device may send the signed data transmission to a receiving device, via one or more proxy devices; in this regards, the receiving device may verify the provenance of the data by verifying the signature, decrypting the data package and evaluating the data ID, and a receiving device may verify the provenance of data even when the data has been transferred between or processed by untrusted intermediary devices in order to proxy devices interface with the producing devices to transfer or process secured data transmissions to the receiving devices (please see ¶[0004] through ¶[0006]).
Per claim 18:
Scheinkman discloses:
receiving a request from a user to identify an entity associated with a selected computer program (At least see ¶[0019] - computing system 104 can receive a command (e.g., an inspect command) from a user … response to the command, first container image);
searching, by an identification module, for the selected computer program in a data structure, the data structure storing provenance data for each of a plurality of computer programs (At least see ¶[0009] - system can then incorporate such source-code provenance data into the container image, so that the provenance data travels with the container image);
based on the identification module finding the selected computer program, identifying a name of an entity associated with the selected computer program, and retrieving a binary file stored in relation to the selected computer program, the binary file including encrypted provenance data (At least see ¶[0008] - container image to determine the location from which the source code was retrieved to compile the software. There is also no way to determine which source code commit was used to compile the software ; also see[0009] - allows other systems and users to determine which specific version of source code was used to generate the piece of software in a container image).
Scheinkman modified by Batts discloses the method as set forth above, but Scheinkman modified by Batts does not explicitly discloses: using a public key associated with the identified entity to decrypt at least a portion of the encrypted provenance data; and
based on the decryption being successful, presenting the decrypted portion of the provenance data to the user.
However, Lee discloses:
using a public key associated with the identified entity to decrypt at least a portion of the encrypted provenance data (At least see ¶[0056] - a holder of the public key may verify that the data transmission 115 including the data package 120 and the data ID is from the device 105); and
based on the decryption being successful, presenting the decrypted portion of the provenance data to the user (At least see ¶[0056] -. a private key or certificate that is different from the exertion key used to encrypt the data. As such, the key (e.g., public key) used to verify that the data was produced by the device 105 or sent from the device 105 may not decrypt or provide access to the data in the data package 120).
It would have been obvious to one ordinary skill in the art before the effective filing date of the claimed invention to incorporate Lee into Scheinkman modified by Batts because Lee’s teaching would provide device may send the signed data transmission to a receiving device, via one or more proxy devices; in this regards, the receiving device may verify the provenance of the data by verifying the signature, decrypting the data package and evaluating the data ID, and a receiving device may verify the provenance of data even when the data has been transferred between or processed by untrusted intermediary devices in order to proxy devices interface with the producing devices to transfer or process secured data transmissions to the receiving devices (please see ¶[0004] through ¶[0006]).
Per claim 19:
Lee also discloses:
based on the decryption being unsuccessful, selecting another entity from the data structure and acquiring another public key associated with the another entity, and attempting to decrypt the binary file using the another public key (At least see ¶[0056] - the key (e.g., public key) used to verify that the data was produced by the device 105 or sent from the device 105 may not decrypt or provide access to the data in the data package; also see ¶[0057] - the receiving device may have access to the encryption key and be able to access the data).
It would have been obvious to one ordinary skill in the art before the effective filing date of the claimed invention to incorporate Lee into Scheinkman modified by Batts because Lee’s teaching would provide device may send the signed data transmission to a receiving device, via one or more proxy devices; in this regards, the receiving device may verify the provenance of the data by verifying the signature, decrypting the data package and evaluating the data ID, and a receiving device may verify the provenance of data even when the data has been transferred between or processed by untrusted intermediary devices in order to proxy devices interface with the producing devices to transfer or process secured data transmissions to the receiving devices (please see ¶[0004] through ¶[0006]).
Per claim 20:
Lee also discloses:
based on the decryption being successful, verifying an authenticity of the selected computer program based on stored information in the data structure (At least see ¶[0005] - providing provenance (e.g., data authenticity and/or proof of origin) of data transferred or processed by multiple entities. The system may include one or more devices that collect, generate or produce data that is transmitted to one or more receiving entities).
It would have been obvious to one ordinary skill in the art before the effective filing date of the claimed invention to incorporate Lee into Scheinkman modified by Batts because Lee’s teaching would provide device may send the signed data transmission to a receiving device, via one or more proxy devices; in this regards, the receiving device may verify the provenance of the data by verifying the signature, decrypting the data package and evaluating the data ID, and a receiving device may verify the provenance of data even when the data has been transferred between or processed by untrusted intermediary devices in order to proxy devices interface with the producing devices to transfer or process secured data transmissions to the receiving devices (please see ¶[0004] through ¶[0006]).
Claims 7-11 are rejected under 35 U.S.C. 103 as being unpatentable over Scheinkman et al. (US 2022/0058011 A1 -herein after Scheinkman) in view of Lee et al. (US 2020/0358788 A1 herein after Lee).
Per claim 7:
Scheinkman discloses:
A method of provenance tracing, comprising:
receiving a request from a user to identify an entity associated with a selected computer program (At least see ¶[0019] - computing system 104 can receive a command (e.g., an inspect command) from a user … response to the command, first container image);
searching, by an identification module, for the selected computer program in a data structure, the data structure storing provenance data for each of a plurality of computer programs (At least see ¶[0009] - system can then incorporate such source-code provenance data into the container image, so that the provenance data travels with the container image);
based on the identification module finding the selected computer program, identifying a name of an entity associated with the selected computer program, and retrieving a binary file stored in relation to the selected computer program, the binary file including encrypted provenance data (At least see ¶[0008] - container image to determine the location from which the source code was retrieved to compile the software. There is also no way to determine which source code commit was used to compile the software ; also see[0009] - allows other systems and users to determine which specific version of source code was used to generate the piece of software in a container image).
Scheinkman discloses the method as set forth above, but Scheinkman does not explicitly discloses: using a public key associated with the identified entity to decrypt at least a portion of the encrypted provenance data; and
based on the decryption being successful, presenting the decrypted portion of the provenance data to the user.
However, Lee discloses:
using a public key associated with the identified entity to decrypt at least a portion of the encrypted provenance data (At least see ¶[0056] - a holder of the public key may verify that the data transmission 115 including the data package 120 and the data ID is from the device 105); and
based on the decryption being successful, presenting the decrypted portion of the provenance data to the user (At least see ¶[0056] -. a private key or certificate that is different from the exertion key used to encrypt the data. As such, the key (e.g., public key) used to verify that the data was produced by the device 105 or sent from the device 105 may not decrypt or provide access to the data in the data package 120).
It would have been obvious to one ordinary skill in the art before the effective filing date of the claimed invention to incorporate Lee into Scheinkman because Lee’s teaching would provide device may send the signed data transmission to a receiving device, via one or more proxy devices; in this regards, the receiving device may verify the provenance of the data by verifying the signature, decrypting the data package and evaluating the data ID, and a receiving device may verify the provenance of data even when the data has been transferred between or processed by untrusted intermediary devices in order to proxy devices interface with the producing devices to transfer or process secured data transmissions to the receiving devices (please see ¶[0004] through ¶[0006]).
Per claim 8:
Lee also discloses:
based on the decryption being unsuccessful, selecting another entity from the data structure and acquiring another public key associated with the another entity, and attempting to decrypt the binary file using the another public key (At least see ¶[0056] - the key (e.g., public key) used to verify that the data was produced by the device 105 or sent from the device 105 may not decrypt or provide access to the data in the data package; also see ¶[0057] - the receiving device may have access to the encryption key and be able to access the data).
It would have been obvious to one ordinary skill in the art before the effective filing date of the claimed invention to incorporate Lee into Scheinkman because Lee’s teaching would provide device may send the signed data transmission to a receiving device, via one or more proxy devices; in this regards, the receiving device may verify the provenance of the data by verifying the signature, decrypting the data package and evaluating the data ID, and a receiving device may verify the provenance of data even when the data has been transferred between or processed by untrusted intermediary devices in order to proxy devices interface with the producing devices to transfer or process secured data transmissions to the receiving devices (please see ¶[0004] through ¶[0006]).
Per claim 9:
Scheinkman discloses:
another entity is selected based on a similarity value and a weight calculated for the another entity (At least see ¶[0023] - difference 140 can be a textual string indicating text of the first container image 114 that does not match the text of the second container image 124. As one particular example, the second computing system 104 can perform the text search and determine the text is present in the first source code 132 but not in the second source code).
Per claim 10:
Lee also discloses:
based on the decryption being successful, verifying an authenticity of the selected computer program based on stored information in the data structure (At least see ¶[0005] - providing provenance (e.g., data authenticity and/or proof of origin) of data transferred or processed by multiple entities. The system may include one or more devices that collect, generate or produce data that is transmitted to one or more receiving entities).
It would have been obvious to one ordinary skill in the art before the effective filing date of the claimed invention to incorporate Lee into Scheinkman because Lee’s teaching would provide device may send the signed data transmission to a receiving device, via one or more proxy devices; in this regards, the receiving device may verify the provenance of the data by verifying the signature, decrypting the data package and evaluating the data ID, and a receiving device may verify the provenance of data even when the data has been transferred between or processed by untrusted intermediary devices in order to proxy devices interface with the producing devices to transfer or process secured data transmissions to the receiving devices (please see ¶[0004] through ¶[0006]).
Per claim 11:
Lee also discloses:
verifying the authenticity includes retrieving a stored hash code and a hash algorithm associated with the selected computer program from the data structure, calculating a hash code using the hash algorithm, and determining that the selected computer program is authentic based on the stored has code matching the calculated hash code (At least see ¶[0131] - data management component 715 may compute a hash of one or more of: the identifier generation key, the metadata, the index data, the data type or the data label associated with the data. In some examples, the data management component 715 may generate the data identifier based on the computed hash).
It would have been obvious to one ordinary skill in the art before the effective filing date of the claimed invention to incorporate Lee into Scheinkman because Lee’s teaching would provide device may send the signed data transmission to a receiving device, via one or more proxy devices; in this regards, the receiving device may verify the provenance of the data by verifying the signature, decrypting the data package and evaluating the data ID, and a receiving device may verify the provenance of data even when the data has been transferred between or processed by untrusted intermediary devices in order to proxy devices interface with the producing devices to transfer or process secured data transmissions to the receiving devices (please see ¶[0004] through ¶[0006]).
CONCLUSION
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ZIAUL A. CHOWDHURY whose telephone number is (571)270-7750. The examiner can normally be reached on 9:30PM 6:30PM Monday -Friday.
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, Hyung S. Sough can be reached on 571-272-6799. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Status information for published applications may be obtained from Patent Public Search tool (for all users) – A link to the Patent Public Search Tool is available at www. Uspto.gov/PatentPublicSearch. To find a U.S. patent or U.S. patent application publication, open the Patent Public Search tool by selecting “Start search”. Type the U.S. patent or U.S. patent application publication number in the “Search” panel without any punctuation and followed by an”.pn.”.
Should you have questions on access to the system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/ZIAUL A CHOWDHURY/ Primary Examiner, Art Unit 2192