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 .
Response to Amendment
Amendment to the Abstract filed on 09/09/2025 has been considered and is entered.
Response to Arguments
Applicant’s arguments, see pages 9-11, filed 09/09/2025, with respect to the rejection(s) of claim(s) 1-7, 9-15, 17-19 under 35 U.S.C. § 103 over Harrington (US 2020/0177397) ("Harrington") in view of Gettys et al. (US 11,138,314) ("Gettys") and Claims 8, 16 and 20 under 35 U.S.C. § 103 over Harrington in view of Gettys et al. and further in view of Chirhart et al. (US 8,630,981) ("Chirhart") have been fully considered and are persuasive. Therefore, the rejections have been withdrawn.
However, upon further consideration, a new ground(s) of rejection is made:
Claim(s) 1, 2, 9, 10, 17, and 18 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Devries (US 20210216636 A1)
Claim(s) 3, 5, 6, 11, 13, and 14 are rejected under 35 U.S.C. 103 as being unpatentable over Devries (US 20210216636 A1) in view of Lapiduz (US 20220244932 A1)
Claim(s) 7, 15, and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Devries (US 20210216636 A1) in view of Liu et al. (US 20200364344 A1)
Claim(s) 4 and 12 are rejected under 35 U.S.C. 103 as being unpatentable over Devries (US 20210216636 A1) in view of Lapiduz (US 20220244932 A1) in view of Liu et al. (US 20200364344 A1)
Claim(s) 8, 16, and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Devries (US 20210216636 A1) in view of Landman (US 20220164452 A1).
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 1-16 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.
The term “some” in claims 1 and 9 is a relative term which renders the claim indefinite. The term “some” is not defined by the claim, the specification does not provide a standard for ascertaining the requisite degree, and one of ordinary skill in the art would not be reasonably apprised of the scope of the invention.
Claim Rejections - 35 USC § 102
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
(a)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
Claim(s) 1, 2, 9, 10, 17, and 18 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Devries (US 20210216636 A1).
Claims 1 and 9:
Devries teaches a method and a system comprising,
at least one processor; and non-transitory computer-readable memory storing instructions that, when executed by the at least one processor, are effective to
(“...program containing lines of code stored on a non-transitory computer readable storage medium that may be executed on a processor...”) [para 29];
identifying first source code
(“...build server 110 may be configured to receive source code 105...”) [FIG 2 item 205; para 15];
generating a first binary package by compiling the first source code
(“...generate an unsigned binary image 115 based on the source code 105...”) [FIG 2 item 205; para 15];
signing the first binary package using cryptographic information to generate a signed binary package comprising the cryptographic information
(“...signing server 120 may be configured to receive the unsigned binary image 115 and utilize a vendor key to sign the unsigned binary image 115 with a binary signature...”) [FIG 2 item 215; para 17];
wherein the cryptographic information used to sign the first binary package comprises at least one of a first signature or a first digest generated using at least a portion of the first source code
(“...The binary signature may represent a state of the source code 105 on which the build server 110 generated the unsigned binary image 115. The binary signature may be used by a destination processing component to verify an authenticity of the binary image...signature mechanism may also utilize any cryptographic function (e.g., a Secure Hash Algorithm 2 (SHA-2) family such as 256 bits (SHA-256) or 512 bits (SHA-512))...”) [para 17];
and sending the signed binary package to a first recipient computing device as at least some portion of a binary software distribution, wherein the cryptographic information is included in the binary software distribution to verify, by the first recipient computing device, that the first binary package corresponds to the first source code
(“...destination processing component may utilize a list of known-valid source code configurations to compare the binary signature of the binary image to verify authenticity...After deployment of the signed binary image 130, the destination processing component or a manual verification process may verify the authenticity of the source code 105 and the build server 110...”) [paras 17, 21].
Claims 2 and 10:
Devries teaches the method and system, of claims 1 and 9 above, further comprising,
wherein the cryptographic information of the first binary package is generated by applying a one-way hash function to the first source code
(“...The signature mechanism may also utilize any cryptographic function (e.g., a Secure Hash Algorithm 2 (SHA-2) family such as 256 bits (SHA-256) or 512 bits (SHA-512))...”) [para 17].
Claim 17:
Devries teaches a method comprising,
Devries teaches a method and a system comprising,
transmitting, by a first software distributor computing device and to an auditor system, first source code
(“...build server 110 may be configured to receive source code 105...”) [FIG 2 item 205; para 15];
generating a first binary package by compiling the first source code
(“...generate an unsigned binary image 115 based on the source code 105...”) [FIG 2 item 205; para 15];
signing, by the first software distributor computing device, the first binary package using cryptographic information to generate a signed binary package comprising the cryptographic information
(“...signing server 120 may be configured to receive the unsigned binary image 115 and utilize a vendor key to sign the unsigned binary image 115 with a binary signature...”) [FIG 2 item 215; para 17];
wherein the cryptographic information used to sign the first binary package comprises at least one of a first signature or a first digest generated using at least a portion of the first source code
(“...The binary signature may represent a state of the source code 105 on which the build server 110 generated the unsigned binary image 115. The binary signature may be used by a destination processing component to verify an authenticity of the binary image...signature mechanism may also utilize any cryptographic function (e.g., a Secure Hash Algorithm 2 (SHA-2) family such as 256 bits (SHA-256) or 512 bits (SHA-512))...”) [para 17];
and sending, by the first software distributor computing device, the signed binary package to a recipient computing device as at least a portion of a binary software distribution, wherein the cryptographic information is included in the binary software distribution to verify, by the recipient computing device, that the first binary package corresponds to the first source code
(“...destination processing component may utilize a list of known-valid source code configurations to compare the binary signature of the binary image to verify authenticity...After deployment of the signed binary image 130, the destination processing component or a manual verification process may verify the authenticity of the source code 105 and the build server 110...”) [paras 17, 21].
Claim 18:
Devries teaches the method, of claim 17 above, further comprising,
wherein the cryptographic information indicates that the first binary package is generated by applying a one-way hash function to the first source code
(“...The signature mechanism may also utilize any cryptographic function (e.g., a Secure Hash Algorithm 2 (SHA-2) family such as 256 bits (SHA-256) or 512 bits (SHA-512))...”) [para 17].
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.
Claim(s) 3, 5, 6, 11, 13, and 14 are rejected under 35 U.S.C. 103 as being unpatentable over Devries (US 20210216636 A1) in view of Lapiduz (US 20220244932 A1).
Claims 3 and 11:
Devries teaches the method and system of claims 1 and 9 above, but does not teach,
sending the first source code to an auditor system, wherein the auditor system generates to generate a second binary package for the first source code
receiving, from the auditor system, a second signature for the second binary package
and incorporating the second signature in the signed binary package prior to sending the signed binary package to the first recipient computing device
However, Lapiduz does teach,
sending the first source code to an auditor system, wherein the auditor system generates to generate a second binary package for the first source code
(“...build artifact(s) 110 may be any product generated by or during software development, and may be any of...application packages, software packages...source code...At step 202, a build artifact may be transmitted to a first validator and a second validator such that the first validator and the second validator receive identical copies of the build artifact...In parallel with steps performed by the first validator, a similar set of steps may be performed by the second validator...”) [paras 28, 39 – examiner notes that the reading of “application packages, software packages...source code” suggests that Lapiduz envisions applying the integrity validation process to any type of build artifact whether it is the source code or the built/compiled application/software package];
(“...After the second validator has received the build artifact, at step 212, the second validator may analyze, and/or conduct a test on, the build artifact. As described herein previously, the analysis performed by the second validator may include testing for known vulnerabilities, a scan for compliance with corporate policies, an open source legal compliance scan, a secrets filter, a smoke test, an end-to-end test, an origin or source scan, or other tests...”) [para 47 – examiner notes that “smoke test, end-to-end test” would inherently require building/compiling source code into a binary of some sort in order to conduct said test(s)];
receiving, from the auditor system, a second signature for the second binary package
(“...If, on the other hand, at step 222 the second validator determines that the build artifact does meet the second criterion, the process with respect to the second validator may proceed to step 232. At step 232, the second validator may generate a hash value corresponding to the build artifact. The second validator may generate the hash value using any known hash function or may use a unique hash function...At step 242, the second validator may generate a second signature corresponding to the build artifact...”) [paras 49-50];
and incorporating the second signature in the signed binary package prior to sending the signed binary package to the first recipient computing device
(“...at step 252, the second validator may add the first signature to a manifest corresponding to the build artifact. After step 252, the process may end with respect to the second validator. If the process 200 proceeds to both of steps 250 and 252, the first signature and the second signature may be collected and/or compiled in the manifest corresponding to the build artifact...”) [para 51];
Therefore, it would have been obvious to one of ordinary skill in the art at the time of applicants' filed invention to incorporate the teachings of Lapiduz into that of Devries in order to provide an additional entity that can corroborate the integrity of the binary package, thereby providing improved verifiable authenticity of the binary package. Devries teaches utilizing a single attester to verify the integrity of a binary image via digital signature, but does not mention having a second independent attester/auditor taking an identical binary image and digitally signing that image as a means of integrity validation of the first signed binary image. Lapiduz teaches the utilization of such a second independent integrity validation attester/auditor that can take an identical binary, digitally sign it and include both the signatures for the same binary from the first and second validators to include as part of an integrity manifest for the binary image/package/application. The teachings of Lapiduz extend the capabilities of Devries by further strengthening the integrity and validation checking process of the binary image/package through this chain of signatures that provides integrity verification for the same binary.
Claims 5 and 13:
Devries teaches the method and system of claims 1 and 9 above, but does not teach,
determining a first auditor system and a second auditor system specified by the first recipient computing device
sending the first source code to the first auditor system
receiving, from the first auditor system, a second signature for a second binary package generated by the first auditor system from the first source code
sending the first source code to the second auditor system
receiving, from the second auditor system, a third signature for a third binary package generated by the second auditor system from the first source code
and incorporating the second signature and the third signature in the signed binary package prior to sending the signed binary package to the first recipient computing device
However, Lapiduz does teach,
determining a first auditor system and a second auditor system specified by the first recipient computing device
(“...first validator and a second validator...”) [FIG 2 illustrates selecting and sending build artifact to two or more validators; para 38];
sending the first source code to the first auditor system
(“...In parallel with steps 210, 220, 230, 240, and 250 performed by the first validator, a similar set of steps 212, 222, 232, 242, and 252 may be performed by the second validator...”) [FIG 1 illustrates build artifact being sent to a first validator; para 46];
receiving, from the first auditor system, a second signature for a second binary package generated by the first auditor system from the first source code
(“...FIG. 2 refers to a first validator and a second validator, but it is to be understood that a number of validators is not to be limited to two and instead may include any number of validators, including three, four, five, or more validators consistent with this disclosure... It is to be understood, however, that steps 210, 220, 230, 240, and 250 need not be performed at the exact same time as any of steps 212, 222, 232, 242, and 252...”) [paras 38, 46 – examiner notes that along with there being a plurality of validators possible in accordance with the teachings of Lapiduz, likewise, the functional steps may be performed in different sequences resulting in the reference point of first, second, third, etc. signatures being relative to which validator outputs each signature before the other just as the claim language does not distinguish the significance of which signature is output in what order];
sending the first source code to the second auditor system
(“...The build artifact(s) 110 may be any product generated by or during software development, and may be any of application containers, application packages, software packages,...source code...a build artifact may be transmitted to a first validator and a second validator such that the first validator and the second validator receive identical copies of the build artifact...”) [paras 28, 39];
receiving, from the second auditor system, a third signature for a third binary package generated by the second auditor system from the first source code
(“...steps performed by the first validator, a similar set of steps may be performed by the second validator...steps 210, 220, 230, 240, and 250 performed by the first validator, a similar set of steps 212, 222, 232, 242, and 252 may be performed by the second validator...the second validator may generate a hash value corresponding to the build artifact...the second validator may generate a second signature corresponding to the build artifact. The second signature may be a digital signature and, more specifically, may be a cryptographic signature...”) [paras 39, 46, 49, 50];
and incorporating the second signature and the third signature in the signed binary package prior to sending the signed binary package to the first recipient computing device
(“...deployment module 130 verifies that a valid signature exists for each of the plurality of validators 120, 122, 124, and 126, the deployment module may deploy the one or more build artifact(s) 110...the second validator may add the first signature to a manifest corresponding to the build artifact. After step 252, the process may end with respect to the second validator. If the process 200 proceeds to both of steps 250 and 252, the first signature and the second signature may be collected and/or compiled in the manifest corresponding to the build artifact...If additional validators are involved in process 200, the first signature, the second signature, and any additional signatures generated by any additional validators may be collected and compiled in the manifest corresponding to the build artifact...”) [paras 36, 37, 46, 51];
Therefore, it would have been obvious to one of ordinary skill in the art at the time of applicants' filed invention to incorporate the teachings of Lapiduz into that of Devries in order to provide a third or more additional entities that can form a signature chain to corroborate the integrity of the binary package, thereby providing a group verifiable authenticity of the binary package. Devries teaches utilizing a single attester to verify the integrity of a binary image via digital signature, but does not mention having a third or more independent attesters/auditors taking the identical binary image and digitally signing that image after performing testing on it as a means of integrity validation of the first signed binary image. Lapiduz teaches the utilization of such a third or more independent integrity validation attester/auditor that can take an identical binary, digitally sign it and include all of the signatures for the same binary from each of the additional validators to include as part of an integrity manifest for the binary image/package/application. The teachings of Lapiduz extend the capabilities of Devries by further strengthening the integrity and validation checking process of the binary image/package through this group chain of signatures that provides integrity verification for the same binary across a plurality of entities.
Claims 6 and 14:
Devries teaches the method and system of claims 1 and 9 above, but does not teach,
wherein the cryptographic information is generated based at least in part on an independent generation of a second binary package for the first source code by a different system than a system generating the first binary package
However, Lapiduz does teach,
wherein the cryptographic information is generated based at least in part on an independent generation of a second binary package for the first source code by a different system than a system generating the first binary package
(“...any number of validators may be involved in process 200 and that any additional validators may perform steps similar to those performed by the first validator and the second validator. It is to be further understood that any additional validators may perform those similar steps in parallel with the steps performed by the first validator and the second validator. If additional validators are involved in process 200, the first signature, the second signature, and any additional signatures generated by any additional validators may be collected and compiled in the manifest corresponding to the build artifact...”) [para 51];
Therefore, it would have been obvious to one of ordinary skill in the art at the time of applicants' filed invention to incorporate the teachings of Lapiduz into that of Devries in order to provide independent additional entities that can form a signature notary chain to corroborate the integrity of the binary package, thereby providing an independently verifiable authenticity of the binary package. Devries teaches utilizing a single attester to verify the integrity of a binary image via digital signature, but does not mention having a plurality of independent attesters/auditors taking the identical binary image and digitally signing that image after performing testing on it as a means of integrity validation of the first signed binary image. Lapiduz teaches the utilization of such a plurality of independent integrity validation attesters/auditors that can take an identical binary, digitally sign it and include all of the signatures for the same binary from each of the additional validators to include as part of an integrity manifest for the binary image/package/application. The teachings of Lapiduz extend the capabilities of Devries by further strengthening the integrity and validation checking process of the binary image/package through this independent group chain of signatures that provides integrity verification for the same binary across a plurality of independent entities.
Claim(s) 7, 15, and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Devries (US 20210216636 A1) in view of Liu et al. (US 20200364344 A1).
Claims 7 and 15:
Devries teaches the method and system of claims 1 and 9 above, but does not teach,
transmitting a first source package comprising the first source code to the first recipient computing device
wherein the at least one of the first signature or the first digest indicates that the first source package matches the first binary package
However, Liu et al. do teach,
transmitting a first source package comprising the first source code to the first recipient computing device
(“...A software release package 160 including the generated certificate is created at 312, encrypted (hashed) at 314, and transmitted to the customer at 316 by the release package generator 150. The transmitted software release package 160 may include the source code files 110, intermediately generated files (optional), final binary files 120, and the signed certificate 140...”) [para 50];
wherein the at least one of the first signature or the first digest indicates that the first source package matches the first binary package
(“...during the trustworthy verification stage at the customer side, the receiver of the software release package 160 can verify the trustworthy relationship between the source code files and the binary files by using the customer's private cryptography key to verify the integrity of the signed certificate 140, i.e., that the signed certificate 140 is free of modifications after being created...”) [para 51]
Therefore, it would have been obvious to one of ordinary skill in the art at the time of applicants' filed invention to incorporate the teachings of Liu et al. into that of Devries in order to verify the integrity and therefore validate the authenticity of the binary at the receiving endpoint in relation to its source code. While Devries teaches an attestation process involving the application of a hashing based digital signature being applied to a binary in relation to its source code, Devries only suggests that the signed binary may be validated using the signature. Liu et al. provides one such implementation for how a digital signature may be utilized to verify the authenticity and therefore the integrity of a binary in relation to the source code that has been signed and sent to a receiving endpoint.
Claim 19:
Devries teaches the method of claim 17 above, but does not teach,
receiving first data indicating a build environment for the first binary package
wherein the generating the first binary package for the first source code is based at least in part on the first data
However, Liu et al. do teach,
receiving first data indicating a build environment for the first binary package
(“...data describing the build environment (BE) 130 is provided to the fingerprint engine 104 in response to control signals from the command engine 102. As just noted, for a build instance, certain building information, including the names and the corresponding fingerprints (e.g., hash values) of the input files, the names and the fingerprints of the intermediately generated files, the names and the fingerprints of the final output files, the fingerprints of the build environment 130, the fingerprints of the TSB tool 100, all file operations that have occurred during the build process, and the exact commands/operations and the order of the commands/operations, are recorded by the fingerprint engine 104 and provided to the certificate engine 106 for use in generation of the signed certificate (SC) 140...”) [para 41];
wherein the generating the first binary package for the first source code is based at least in part on the first data
(“...the signed certificate 140 includes a variety of information 142 that establishes the trustworthiness that the binary files 120 are generated from the provided source code files 110. For example, the information 142 may include, inter alia, information regarding the build environment 130, the software framework of a trustworthy build including the root of trust, the source code files 110 including any path and hash values, the final binary files 120, other operations performed on the files by TSB tool 100, and the signature with the customer's public key from memory 108...”) [para 42]
Therefore, it would have been obvious to one of ordinary skill in the art at the time of applicants' filed invention to incorporate the teachings of Liu et al. into that of Devries in order to provide for an attestation of a plurality of parameters specific to the particular build environment and process for the source code as it is built/compiled into a binary. This would allow for a much more detailed attestation criteria as including a plurality of details regarding the build environment utilized for creating the binary would be much more difficult to forge, making the integrity validation of the binary much more robust. While Devries teaches utilizing digital signatures to sign a binary with respect to its source code, Devries is silent regarding what kinds of details may be included in the generation of the digital signature. Liu et al. provides for specific details of an implementation that would extend the capabilities of Devries through the inclusion of detailed information as part of the signature process for the integrity and authentication of the binary.
Claim(s) 4 and 12 are rejected under 35 U.S.C. 103 as being unpatentable over Devries (US 20210216636 A1) in view of Lapiduz (US 20220244932 A1) in view of Liu et al. (US 20200364344 A1).
Claims 4 and 12:
Devries and Lapiduz teach the method and system of claims 3 and 11 above, but their combination do not teach,
sending metadata describing a build environment to the auditor system
wherein the metadata is used during the generation of the second binary package
However, Liu et al. do teach,
sending metadata describing a build environment to the auditor system
(“...data describing the build environment (BE) 130 is provided to the fingerprint engine 104 in response to control signals from the command engine 102. As just noted, for a build instance, certain building information, including the names and the corresponding fingerprints (e.g., hash values) of the input files, the names and the fingerprints of the intermediately generated files, the names and the fingerprints of the final output files, the fingerprints of the build environment 130, the fingerprints of the TSB tool 100, all file operations that have occurred during the build process, and the exact commands/operations and the order of the commands/operations, are recorded by the fingerprint engine 104 and provided to the certificate engine 106 for use in generation of the signed certificate (SC) 140...”) [para 41];
wherein the metadata is used during the generation of the second binary package
(“...the signed certificate 140 includes a variety of information 142 that establishes the trustworthiness that the binary files 120 are generated from the provided source code files 110. For example, the information 142 may include, inter alia, information regarding the build environment 130, the software framework of a trustworthy build including the root of trust, the source code files 110 including any path and hash values, the final binary files 120, other operations performed on the files by TSB tool 100, and the signature with the customer's public key from memory 108...”) [para 42]
Therefore, it would have been obvious to one of ordinary skill in the art at the time of applicants' filed invention to incorporate the teachings of Liu et al. into that of Devries and Lapiduz in order to provide for an attestation of a plurality of parameters specific to the particular build environment and process for the source code as it is built/compiled into a binary. This would allow for a much more detailed attestation criteria as including a plurality of details regarding the build environment utilized for creating the binary would be much more difficult to forge, making the integrity validation of the binary much more robust. While the combination of Devries and Lapiduz teach utilizing digital signatures to sign a binary with respect to its source code utilizing a plurality of attesters/validators, Devries and Lapiduz are silent regarding what kinds of details may be included in the generation of the digital signature. Liu et al. provides for specific details of an implementation that would extend the capabilities of Devries through the inclusion of detailed information as part of the signature process for the integrity and authentication of the binary.
Claim(s) 8, 16, and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Devries (US 20210216636 A1) in view of Landman (US 20220164452 A1).
Examiner note: Claims 8, 16, and 20 contain claim language that amounts to nothing more than non-functional descriptive material which does not impart any meaningful Patentable weight to the functions or structure of these claims. That is, the description of a specific type of binary package does not lend itself to changing anything functional in the method claim tree of claims 1 and 17 or to changing anything structural in the system claim tree of claim 9. Examiner has presented prior art which teaches similar package types as the claim language of these claims do not require anything more than a non-functional descriptive equivalent of the package type(s) present.
Claims 8, 16, and 20:
Devries teaches the method of claim 1, the system of claim 9, and the method of claim 17 as above, but does not teach,
wherein the first binary package is an RPM package, an MSI package, a DEB package, an IPA package, or an APK package
However, Landman teaches,
wherein the first binary package is an RPM package, an MSI package, a DEB package, an IPA package, or an APK package
(“...Debian...RPM...”) [para 60];
Therefore, it would have been obvious to one of ordinary skill in the art at the time of applicants' filed invention to incorporate the teachings of Landman into that of Devries as Debian and RPM packages are common types of packages for two of the most common Linux distributions (e.g. Debian and Debian based, as well as, Red Hat and Red Hat based distributions). By having support for two of the most common package types and Linux operating system distributions, wider support and compatibility can be had.
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Oscar Louie whose telephone number is (571) 270-1684 and E-mail address is OSCAR.LOUIE@USPTO.GOV. Note that a form SB-439 must be on file in order to conduct correspondence by E-mail, however, E-mail may be utilized to arrange time(s) for interview(s) without the SB-439 form. The examiner can normally be reached on Monday through Thursday between 05:30AM-03:30 PM.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
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.
/OSCAR A LOUIE/Supervisory Patent Examiner, Art Unit 2445
Prosecution Insights