Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Claim Rejections - 35 USC § 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 7 and 18 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 7 recites “the one or more lines of user software code”. This term lacks antecedent basis. For the purposes of this examination the term will be understood to describe the software generally.
Claim 18 recites “the code checking system is automatically triggered”. Parent claim 1 recites “receiving … a user query”. These limitations appear contradictory accordingly the scope of the claim is unclear.
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.
Claim(s) 1, 4, 6, 8, 11, 16-17 and 19-20 is/are rejected under 35 U.S.C. 102(a) as being anticipated by CA 2 935 130 to Kamaludeen et al. (Kamaludeen).
Claims 1, 19 and 20: Kamaludeen discloses a method for securely identifying deficiencies in software code, comprising:
by a code checking system:
receiving, from a user device, a user query comprising obfuscated user software code data and a user-specified software code portion specification (§7.1.B, 1st par. “The data owner encrypts the data set … and sends the result to the cloud. The public key is also uploaded with the data set”, §7.1.B, 2nd par. “n-bit plaintexts … encrypted as n-bit blocks”);
obtaining, based on the user-specified software code portion specification, one or more obfuscated reference software code data structures constructed from reference software code associated with one or more predefined deficiencies (§7.1.B, 1st par. “the anti-virus company encrypts the standard and generic signatures using the data owner’s public key and sends them to the cloud for testing”);
comparing the obfuscated user software code data with the one or more obfuscated reference software code data structures (§7.1.B, 1st par. “computes the difference between the encrypted data and test sequences”);
if the obfuscated user software code data matches at least one of the obfuscated reference software code data structures, identifying the one or more predefined deficiencies in the obfuscated user software code data (§7.1.B, 1st par. “sends the results back to the data owner); and
providing an indication of the identified one or more predefined deficiencies to the user device for flagging, in a software development environment at the user device, one or more lines of user software code associated with the obfuscated user software code data (§7.1.B, 1st par. “the anti-virus server sends the malware scan results to data owner”).
Claim 4: Kamaludeen discloses the method of claim 1, wherein the obfuscated user software code data is generated at the user device by:
extracting, at the user device, a plurality of user software code portions from the user software code (§7.1.B, 2nd par. “a Paillier cryptosystem which accepts n-bit plaintexts … encrypted as n-bit blocks”); and
constructing obfuscated user software code data by obfuscating the plurality of user software code portions (§7.1.B, 1st par. “The data owner encrypts the data set … and sends the result to the cloud. The public key is also uploaded with the data set”).
Claim 6: The method of claim 1, wherein the one or more lines of user software code associated with the obfuscated user software code data are not accessible by the code checking system (§7.1.A “content of the files … remains private”).
Claim 8: Kamaludeen discloses the method of claim 1, wherein the one or more predefined deficiencies comprise:
one or more copyright restrictions, one or more trademark restrictions, one or more licenses, one or more vulnerabilities (§7.1.A, “malware scanning”), or any combination thereof.
Claim 11: Kamaludeen discloses the method of claim 1, wherein the one or more obfuscated reference software code portions are obfuscated by performing a cryptographic hash function on each reference software code portion of the plurality of reference software code portions (§7.1.B, 3rd par. “encrypts the negation of a nh-bit hash signature”).
Claim 16: Kamaludeen discloses the method of claim 1, wherein the plurality of reference software code portions are obfuscated using an Oblivious RAM-based technique, a Homomorphic encryption technique (§7.1.B, 1st par. “homomorphic encryption”), a Private Information Retrieval protocol, or a Secure Multiparty Computation Protocol (SMCP).
Claim 17: Kamaludeen discloses the method of claim 1, wherein the code checking system is installed on the user device (§4.0, 1st par. A malware scanner … accessed sole by the data owner”) or one or more remote devices (§7.1.A, 1st par. “anti-virus server”).
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.
Claim(s) 2-3 and 5 is/are rejected under 35 U.S.C. 103 as being unpatentable over CA 2 935 130 to Kamaludeen et al. (Kamaludeen) in view of US 2023/0359442 to Ziegler et al. (Ziegler).
Claim 2: Kamaludeen discloses the method of claim 1, wherein the one or more obfuscated reference software code data structures are constructed by:
extracting, with a specification equivalent to the user-specified software code portion specification, a plurality of reference software code portions from the reference software code (§7.1.B, 2nd par. “a Paillier cryptosystem which accepts n-bit plaintexts … encrypted as n-bit blocks”); and
constructing the one or more obfuscated reference software code data structures by obfuscating the plurality of reference software code portions (§7.1.B, 1st par. “The data owner encrypts the data set … and sends the result to the cloud. The public key is also uploaded with the data set”).
Kamaludeen does not disclose:
extracting, via a rolling window having a specification, a plurality of reference software code portions from the reference software code.
Ziegler teaches:
extracting, via a rolling window having a specification, a plurality of reference software code portions from the reference software code (par. [0054] “a rolling window” … The portion of text 822 is compared with the portion of text 842”).
It would have been obvious at the time of filing to extract reference code portions using a rolling window. Those of ordinary skill in the art would have been motivated to do so as an alternative method of comparing source code which would have produced only the expected results.
Claim 3: Kamaludeen and Ziegler teach the method of claim 2, wherein each reference software code portion of the plurality of reference software code portions comprises the same number of lines of software code (Ziegler par. [0055] “if the portion of text 842 is 10 lines … the rolling window also is 10 lines”); and
wherein each reference software code portion has overlapping lines of software code with a neighboring reference software code portion (Ziegler par. [0054] “the window moves by a predetermined number of lines (e.g., 1 line)”).
Claim 5: Kamaludeen discloses the method of claim 4, wherein each user software code portion comprises the same number of bits of software code (§7.1.B, 2nd par. “a Paillier cryptosystem which accepts n-bit plaintexts … encrypted as n-bit blocks”); and
wherein each user software code portion has no overlapping lines of software code with a neighboring user software code portion (§7.1.B, 2nd par. “a Paillier cryptosystem which accepts n-bit plaintexts … encrypted as n-bit blocks”, note that the blocks here are disclosed as being discrete objects).
Kamaludeen does not explicitly disclose the code portion comprises the same number of lines of software code.
Ziegler teaches code portions comprising the same number of lines of software code (par. [0055] “10 lines of code”).
It would have been obvious at the time of filing to extract a number of lines. Those of ordinary skill in the art would have been motivated to do so as an alternative method of comparing source code which would have produced only the expected results.
Claim(s) 7 is/are rejected under 35 U.S.C. 103 as being unpatentable over CA 2 935 130 to Kamaludeen et al. (Kamaludeen) in view of Official Notice.
Claim 7: Kamaludeen discloses the method of claim 1, but does not disclose wherein the one or more lines of user software code associated with the obfuscated user software code data are generated by a machine-learning or AI model.
It is officially noted that lines of code generated by a machine-learning or AI model were well known in the art.
It would have been obvious at the time of filing to perform Kamaludeen’s detection on code generated by a machine-learning or AI model. Those of ordinary skill in the art would have been motivated to do so, as with any other code, to detect malware.
Claim(s) 9-10 is/are rejected under 35 U.S.C. 103 as being unpatentable over CA 2 935 130 to Kamaludeen et al. (Kamaludeen) in view of US 8,819,856 to Tiffe et al. (Tiffe)
Claim 9: Kamaludeen discloses the method of claim 1, but does not disclose:
normalizing the reference software code.
Tiffe teaches normalizing reference software code (col. 4, lines 13-16 “Normalizing source code statements”)
It would have been obvious at the time to normalize the reference software code. Those of ordinary skill in the art would have been motivated to do so “so that such differences do not hinder the identification” (Tiffe col. 4, lines 13-16).
Claim 10: Kamaludeen and Tiffe teach the method of claim 9, wherein normalizing the reference software code comprises:
removing one or more whitespaces from the reference software code, removing one or more comments from the reference software code (Tiffe col. 4, lines 13-16 “removes … comments”), removing one or more special symbols from the reference software code, reformatting the reference software code, renaming one or more parameters or identifiers in the reference software code (Tiffe col. 4, lines 13-16 “replaces the variables and functions with tokens”), or any combination thereof.
Claim(s) 12 is/are rejected under 35 U.S.C. 103 as being unpatentable over CA 2 935 130 to Kamaludeen et al. (Kamaludeen) in view of US 2017/0180416 to Giura et al. (Giura)
Claim 12: Kamaludeen discloses the method of claim 1, but does not disclose wherein each obfuscated reference software code data structure of the one or more obfuscated reference software code data structures comprises a Bloom filter, a Cuckoo filter, a Ribbon filter, an XOR filter, or a Binary Fuse Filter.
Giura teaches an obfuscated reference software code data structure comprises a Bloom filter (par. [0044] “The bloom filters 706, 708, 710”), a Cuckoo filter, a Ribbon filter, an XOR filter, or a Binary Fuse Filter.
It would have been obvious at the time of filing to incorporate Bloom filters. Those of ordinary skill in the art would have been motivated to do so as a known means of identifying malware which would have produced only the expected results.
Claim(s) 13-14 is/are rejected under 35 U.S.C. 103 as being unpatentable over CA 2 935 130 to Kamaludeen et al. (Kamaludeen) in view of US 2020/0026512 to Yu et al. (Yu).
Claim 13: Kamaludeen discloses the method of claim 1, wherein the user query comprises a plurality of parameters (§7.1.B, 1st par. “The data owner encrypts the data set … and sends the result to the cloud. The public key is also uploaded with the data set”) comprising:
virus/malware definitions (§7.0.B, 3rd par. “sending the keyed hash of the signature … to the cloud”).
Kamaludeen does not explicitly disclose:
parameters comprising one or more programming languages to check, one or more code licenses to check, one or more organizations to check, one or more normalization rules, or any combination thereof.
Yu teaches:
one or more programming languages to check, one or more code licenses to check, one or more organizations to check, one or more normalization rules, or any combination thereof (par. [0033] “detects open-source license(s) … files with copyright”).
It would have been obvious at the time of filing to include parameters comprising licenses. Those of ordinary skill in the art would have been motivated to do so to ensure the code complies with licensing requirements.
Claim 14: The method of claim 13, wherein the one or more obfuscated reference software code data structures are selected based on the plurality of parameters in the user query (Kamaludeen §7.0.B, 3rd par. “sending the keyed hash of the signature … to the cloud”, §7.1.B, 2nd par. “using the user’s public key”).
Claim(s) 15 and 18 is/are rejected under 35 U.S.C. 103 as being unpatentable over CA 2 935 130 to Kamaludeen et al. (Kamaludeen) in view of US 2019/0171846 to Conikee et al. (Conikee)
Claim 15: Kamaludeen discloses the method of claim 1, but does not explicitly disclose wherein flagging the one or more lines of user software code associated with the obfuscated user software code data comprises highlighting, marking, or annotating the one or more lines of user software code.
Conikee teaches:
flagging one or more lines of user software code comprises highlighting, marking, or annotating the one or more lines of user software code (par. [0069] “graphically highlight code elements”).
It would have been obvious at the time of filing to highlight, mark, or annotate the lines of code. Those of ordinary skill in the art would have been motivated to do so as a commonplace method of identifying portions of code which would have produced only the expected results.
Claim 18: Kamaludeen discloses the method of claim 1, but does not explicitly disclose wherein the code checking system is automatically triggered by the software development environment or IDE.
Conikee teaches a code checking system automatically triggered by a software development environment or IDE (par. [0069] “code elements automatically identified”).
It would have been obvious to automatically trigger the code checking system. Those of ordinary skill in the art would have been motivated to do so in order to ensure the code is checked when appropriate and reduce the burden on developers.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JASON D MITCHELL whose telephone number is (571)272-3728. The examiner can normally be reached Monday through Thursday 7:00am - 4:30pm and alternate Fridays 7:00am 3:30pm.
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, Lewis Bullock can be reached at (571)272-3759. 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.
/JASON D MITCHELL/Primary Examiner, Art Unit 2199