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 .
Detail Action
This office action is response to the application 17/938,174 filed on 10/05/2022. Claims 1-20 are pending in this communication.
Examiner’s Note
The examiner is requesting the applicant’s representative to provide direct phone number and/or mobile phone number in next communication, which will be very helpful to advance the prosecution.
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 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. OR
(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.
Claims 1, 8 & 15 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by SHUKLA; Jayant (US 2008/0016339 A1).
Regarding Claim 1, SHUKLA anticipated a computer implemented method for detecting a problematic source code, the computer implemented method comprising:
loading, by a computer system, a source code into a first memory {Fig. 8 & [0076], “these malware are detected by verifying the integrity of the kernel and of the application images loaded into memory … it first translates the on-disk image to an expected in-memory image (48) … As shown in FIG. 8, hash of the expected in-memory image is computed” … [0078], “small variation in the source code of the malware can render”};
loading, by the computer system, a rendered source code into a second memory, wherein the rendered source code is a rendered version of the source code {Fig. 8 & [0076], “these malware are detected by verifying the integrity of the kernel and of the application images loaded into memory … As shown in FIG. 8, hash of the expected in-memory image is computed and that hash 60 is compared with the observed in-memory (49) hash 61 of the application or kernel or module image”};
determining, by the computer system, a difference between the source code and the rendered source code in the second memory; determining, by the computer system, whether a problematic source code is present within the source code using the difference {[0076], “Any change made to the application or kernel image while it is being loaded into memory, no matter how small, will be identified” … Fig. 8 element ‘Match’ and element 52 – Malware detected … [0081], “malware that hides part or all of its components to evade detection by manipulating kernel objects is also detected. The mechanism to detect malware hidden in the kernel is based on cross checking the observations from multiple sources which gives further insight into the behavior of the application”}; and
performing, by the computer system, a set of actions with respect to the problematic source code in response to determining that the problematic source code is present in the source code {Fig. 9 & [0094], “If the malware is at the application layer in the form of a malicious or infected application, it is quarantined by tightening the sandbox. Once the application is quarantined, it simply cannot take any action that is controlled by the sandbox. The quarantined application will not be able of read or write files, make network connections, read or write registry entries, and launch any executable code”}.
Regarding claim 8, claim 8 is claim to a system using the method of claim 1. Therefore, claim 8 is rejected for the reasons set forth for claim 1.
Regarding claim 15, claim 15 is claim to a computer program product using the method of claim 1. Therefore, claim 15 is rejected for the reasons set forth for claim 1.
Claim Rejections - 35 USC § 103
The following is a quotation of AIA 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.
Claims 6, 13 & 20 are rejected under AIA 35 U.S.C. 103 as being unpatentable over SHUKLA; Jayant (US 2008/0016339 A1) in view COBCROFT; Garrick et al. (US 2005/0283758 A1).
Regarding Claim 6, SHUKLA anticipated all the features of claim 1, SHUKLA, however does not disclose
the problematic source code is a process modified by control symbols controlling a display of text using a bidirectional algorithm.
In an analogous reference COBCROFT discloses
the problematic source code is a process modified by control symbols controlling a display of text using a bidirectional algorithm {[0011], “t is presently known to provide a system for developing a user interface whereby a programmer is enabled to not only build a visual user interface and generate code from it, but also to then modify or add to the code and have the changes or additions reflected in the visual representation of the user interface. This is often referred to as "round-trip engineering" or "bi-directional programming". For example, Microsoft commercialized such a concept in the product known as Visual Basic” … [0035], “the extended element construct contains a generic data structure for the visual representation including a start element, an end element and a means of representing a symbol table. In still a further form, the extended element construct contains a generic data structure for the representation of a collection of symbols or a symbol table”}.
Before the effective filing date of the claimed invention, it would have been obvious to one with ordinary skill in the art to modify SHUKLA’s technique of ‘identifying malware or data intrusion in source code’ for ‘using bi-directional programming using symbol table’, as taught by V. The motivation is: Bi-directional programming allows for analysis of data flow both forwards (from definition to use) and backwards (from use to definition). This enables a more complete understanding of how data is manipulated and where it originates, making it easier to identify suspicious data flows associated with malware.
Regarding claim 13, claim 13 is a dependent claim of claim 8, claim 13 is claim to system using the method of claim 6. Therefore, claim 13 is rejected for the reasons set forth for claim 6.
Regarding claim 20, claim 20 is a dependent claim of claim 15, claim 20 is claim to computer program product using the method of claim 6. Therefore, claim 20 is rejected for the reasons set forth for claim 6.
Claims 7 & 14 are rejected under AIA 35 U.S.C. 103 as being unpatentable over SHUKLA; Jayant (US 2008/0016339 A1) in view of LONG; Jeremy W. (US 12,373,558 B1).
Regarding Claim 7, SHUKLA anticipated all the features of claim 1, SHUKLA, however does not disclose
wherein the set of actions is selected from at least one of removing the problematic source code from the source code; sending an alert indicating a presence of the problematic source code in the source code; graphically identifying the problematic source code in the source code; adding a pattern for the problematic source code to a Trojan source code report repository; sending the source code with an identification of the problematic source code to a reviewer; correcting the problematic source code in the source code in the first memory and saving the source code corrected for the problematic source code as a new version of the source code for reviewing; determining a severity level for the problematic source code according to an impact scope; initiating an investigation to determine a root cause of the problematic source code; initiating the investigation to determine a contributor of the problematic source code; initiating a cleanup session to identify and correct the problematic source code in other source code in a source code database; reporting the problematic source code to a security entity; adding the contributor of the problematic source code to a watch list; suspending an account of the contributor of the problematic source code; broadcasting the report of the problematic source code to another integrated development environment; or reporting the problematic source code as a new case to the Trojan source code report repository.
In an analogous reference LONG discloses
wherein the set of actions is selected from at least one of removing the problematic source code from the source code; sending an alert indicating a presence of the problematic source code in the source code; graphically identifying the problematic source code in the source code; adding a pattern for the problematic source code to a Trojan source code report repository; sending the source code with an identification of the problematic source code to a reviewer; correcting the problematic source code in the source code in the first memory and saving the source code corrected for the problematic source code as a new version of the source code for reviewing; determining a severity level for the problematic source code according to an impact scope; initiating an investigation to determine a root cause of the problematic source code; initiating the investigation to determine a contributor of the problematic source code; initiating a cleanup session to identify and correct the problematic source code in other source code in a source code database; reporting the problematic source code to a security entity; adding the contributor of the problematic source code to a watch list; suspending an account of the contributor of the problematic source code; broadcasting the report of the problematic source code to another integrated development environment; or reporting the problematic source code as a new case to the Trojan source code report repository {col. 4 line 65 – col. 5 line 7, “The testing and bug fixing portions may attempt to detect malicious code or malware within the source code received from source code repository 22 and/or the build artifacts received from build artifact repository 26. For example, malicious code detection primarily leverages two approaches: (1) binary analysis in which a computer system scans the binaries for signatures of known malicious code; and (2) source code analysis in which a computer system analyzes or scans the source code for dangerous coding patterns” … col. 11 lines 29-34, “build integrity validation system 48A may generate a notification indicating that additional code or data was potentially introduced during the software build process of the source code at build server 44A that produced the build artifact. Build integrity validation system 48A may send the report and/or the notification to admin device 47A”. Examiner’s note: “reporting the problematic source code to a security entity” option is addressed}.
Before the effective filing date of the claimed invention, it would have been obvious to one with ordinary skill in the art to modify SHUKLA’s technique of ‘identifying malware or data intrusion in source code’ for ‘sending notification to a central security authority’, as taught by LONG, in order to isolate and resolve the issue. The motivation is: identifying malware in source code and sending a notification to a central authority enables early threat detection, improved incident response, and proactive prevention of wider damage. This centralized approach provides a global view of a breach, allowing for the swift implementation of security measures across the entire organization, unlike isolated detection which might only address a single point of failure.
Regarding claim 14, claim 14 is a dependent claim of claim 8, claim 14 is claim to system using the method of claim 7. Therefore, claim 14 is rejected for the reasons set forth for claim 7.
Allowable subject matter
Claims 2 & 3 will be allowable if written in independent form with base method claim 1; Claims 9 & 10 will be allowable if written in independent form with base system claim 8; and Claims 16 & 17 will be allowable if written in independent form with base computer program product claim 16.
Reasons of allowance: what is missing from the prior arts is: wherein analyzing, by the computer system, the problematic source code to determine the set of actions using the set of criteria comprises: searching, by the computer system, a Trojan source pattern repository for the problematic source code; and determining, by the computer system, the set of actions based on a result of searching the Trojan source pattern repository.
Therefore, claims 2-5, 9-12 and 16-19 are objected.
Conclusion
Following prior art has been consulted but is not applied:
JENNINGS; Joshua Holden et al. (US 2023/0019837 A1) – System for malicious software detection: “Binary libraries may be prepared by a compiler from source code and the components packaged by a library archiver, part of the software development suite. Libraries for scripting languages may be simply a file containing a collection of function or object declarations in source code but may also contain compiled binary language extensions” … “software and/or components may include software and/or components such as but not limited to ransomware, file less malware, spyware, adware, trojans, worms, rootkits, keyloggers, bots, mobile malware”.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to QUAZI FAROOQUI whose telephone number is (571) 270-1034 or Quazi.farooqui@uspto.gov. The examiner can normally be reached on Monday-Friday 9:00 am to 5:30 pm, EST. If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Bill Korzuch can be reached on (571) -272-7589 or William.Korzuch@USPTO.GOV. The fax phone number for Examiner Farooqui assigned is 571-270-2034.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-flee). 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.
/QUAZI FAROOQUI/
Primary Examiner, Art Unit 2491