Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
This action is in response to the claims filed 8/06/2025. Claims 1-4, 6-21 are pending. Claims 1 (a method), 9 (a machine), and 16 (a computer readable medium) are independent.
Claim Interpretation
“an authorized program, wherein the authorized program is authorized to modify system security settings of an operating system without using a security interface provided for modifying the security settings”
This is a characterization of a type of program within the Z/OS system, such as those outlined in claim 3. This does not require detecting or determining that a program has these properties, it is merely a statement as to the field of use of the claim.
“a modification of a system security setting without using the security interface”
This is a characterization of a type of access within the Z/OS system, such as those outlined in claims 4 and 6. It does not specify or require checking a security interface because “the security interface” is a separate unused/claimed portion of the Z/OS system.
Response to Arguments
The 112(b) rejection has been withdrawn due to the amendments of 8/06/2025.
Applicant's arguments filed 8/06/2025 have been fully considered but they are not persuasive.
In the remarks p. 11, ¶ 2, Applicant asserts that Bishop teaches away from static analysis. This argument is not persuasive as Bishop cannot teach away from itself.
Examiner notes that in the context of Applicant’s disclosure, permissions within Z/OS control blocks, the “Detecting ACEE modifications” is the main reference of relevance. ‘Detecting ACEE modifications’ does not disclose: “The security analysis tool 301 the determines whether any instructions modify storage in the system control block with an emphasis on security fields such as ACEEPRIV, ACEESPEC, ACEEOPER, JSCBAUTH and JSCBPASS” (Applicant’s specification ¶ 36).
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1-4 and 6-21 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more. The claim(s) recite(s) a mental process of debugging software code; debugging and reviewing software to determine maliciousness or faults has long been practiced by human programmers. See MPEP 2106.04(a)(2).III. This judicial exception is not integrated into a practical application because the performance of the claimed steps (1-20) do not (a) improve the functioning of the claimed computer (the computer performing static code analysis); (b) require a particular machine; nor (c) apply the human mental process of code debugging in a meaningful way beyond asserting it be done by a machine. See MPEP 2106.04(d). The claim(s) include the additional element of “removing authorization from unsafe libraries … or uninstalling the authorized program”; however, uninstalling programs and/or manually changing permissions on files and executables that are undesirable is a well-understood, routine, and conventional activity and does not amount to significantly more than the judicial exception itself; additionally, humans are capable of commanding computers to uninstall programs that are not desired. See MPEP 2106.05.
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, 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) 1, 2, 4, and 6-20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Bishop et al., US 9,798,884 (published 2017), in view of Detecting ACEE modifications, hereafter referred to as Detecting, (published 2021-05) and ACEE: Accessor Environment Element, hereafter referred to as ACEE (published 2021-04).
As to claims 1, 9, and 16, Bishop discloses a method/machine/CRM comprising:
A method detecting a security bypass through binary code analysis, the method comprising:
identifying one or more binary files (“With reference to FIG. 1, in a vulnerability analysis system 100, a software system/program 102 in which vulnerabilities are to be detected is analyzed by an analyzer 110. The software 102 may include one or more source files 104, one or more binaries 106, and/or other files 108, such as script files.” Bishop col. 5, ln. 33.) of an authorized program, (any program can be considered authorized unless particular criteria for authorization are required)
performing static code analysis of code of the one or more binary files, performing the static code analysis comprising disassembling the code to analyze (“the method includes obtaining the set of detected vulnerabilities via static and/or dynamic source code analysis.” Bishop Col. 4, ln. 30) control block structures , of the code, to determine whether a security setting of an operating system is being modified by the instructions; (“This vulnerability in combination with a vulnerability associated with improper privilege management (e.g., CWE 269) can cause privilege escalation or improper grant of privilege to an unauthorized user.” Bishop col. 7, ln. 28. See claim 4, system control block being related to user privileges in an OS.)
determining, based on performing the static code analysis, (“The analyzer 110 may include a static analyzer 112 and/or a dynamic analyzer 114. …The defect/vulnerability list 120 may also include for each identified vulnerability additional information such as the source file and/or binary in which that particular vulnerability was found,” Bishop col. 5, ln. 38) that the authorized program includes a potential security vulnerability when the security setting is being modified, (“This vulnerability in combination with a vulnerability associated with improper privilege management (e.g., CWE 269) can cause privilege escalation or improper grant of privilege to an unauthorized user.” Bishop col. 7, ln. 28. See claim 4, system control block being related to user privileges.)
generating, in response to determining that the authorized program includes the potential security vulnerability, a security report that identifies the potential security vulnerability. (“the authors of the respective modules (e.g., files, classes, functions, etc.) in which the vulnerabilities 160, 162, 164 were detected are identified.” Bishop col. 6, ln. 33)
causing an action to be performed, (Bishop col. 6, ln. 33)
Bishop discloses that static and dynamic analysis are equally applicable to determine coding errors or “less than perfect adherence to a recommended coding practice (e.g. Applicant’s intended use of a ‘security interface’), Bishop col. 2 ll. 7-11.
Bishop does not disclose:
(as to claim 9: “program configured to execute on a computing system based on Z/Architecture;”)
control block structures and offsets being referenced by instructions
… that identifies the potential security vulnerability
causing the action to be performed including removing authorization from unsafe libraries associated with the authorized program or uninstalling the authorized program.
Detecting discloses:
(as to claim 9: “program configured to execute on a computing system based on Z/Architecture;”) (“See z/OS Security Server RACF Messages and Codes for more information about message IRR421I.” Detecting page 1)
control block structures … being referenced by instructions
(“The ACEE (accessor environment element) is a control block…. An application running in an authorized state can make modifications directly to the ACEE in storage after its creation. Such a modification would be outside the involvement of the security product, and the application must take caution to ensure that such updates do not interfere with normal system processing. Some applications might make an ACEE change to temporarily or permanently elevate the privilege of the user. This use is not necessarily malicious, and may be beneficial…. When the ACEECHK class is active and RACLISTed, RACF command and authorization processing will detect certain changes made to the ACEE that affect authorization. When a modification is detected, RACF issues message IRR421I to the security console…. See z/OS Security Server RACF Messages and Codes for more information about message IRR421I.” Detecting page 1)
… that identifies the potential security vulnerability
(“When a modification is detected, RACF issues message IRR421I to the security console. IRR421I contains information to possibly help you determine whether the modification is expected. See z/OS Security Server RACF Messages and Codes for more information about message IRR421I.” Detecting page 1)
causing the action to be performed including removing authorization from unsafe libraries associated with the authorized program or uninstalling the authorized program. (“When the ACEECHK class is active and RACLISTed, RACF command and authorization processing will detect certain changes made to the ACEE that affect authorization. When a modification is detected, RACF issues message IRR421I to the security console.” Detecting page 1. “You can request that RACF abend the running program when a modified ACEE is detected. This will result in a 4C6 abend with reason code X'ACE'.” Detecting page 4)
A person of ordinary skill in the art before the effective filing date of the claimed invention would have combined Bishop with Detecting by including the privilege escalation types of Detecting in the system of Bishop. It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to combine Bishop with Detecting in order to determine whether the permission modification is intended or a potentially malicious or misconfigured application; Detecting p. 1, Bishop col. 7, ln. 22.
Detecting in view of Bishop does not explicitly disclose: and offsets
ACEE discloses:
and offsets see ACEE Table 1 showing a plurality of offsets) defined by pointers (“2. If you use ACEEIEP, it must point to an area of storage you obtained using a GETMAIN from within the RACINIT post-processing exit…. b. ACEEIEP contains a pointer,” ACEE p. 2) and offsets. (see ACEE Table 1 showing a plurality of offsets).
A person of ordinary skill in the art before the effective filing date of the claimed invention would have combined Bishop in view of Detecting with the teachings of ACEE by utilizing the structure of ACEE as defined in ACEE to implement the ACEE of Bishop. It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention would have combined Bishop in view of Detecting with ACEE in order to implement the ACEE data structure as required by Detecting.
As to claims 2 Bishop in view of Detecting and ACEE discloses the method/machine/CRM of claims 1, 9, and 16, and further discloses:
Wherein the operating system is Z/OS. (“See z/OS Security Server RACF Messages and Codes for more information about message IRR421I.” Detecting page 1)
As to claims 4, 10, and 17 Bishop in view of Detecting and ACEE discloses the method/machine/CRM of claims 1, 9, and 16, and further discloses:
wherein the modification of the system security settings includes a modification of a Z/OS system control block (“The ACEE (accessor environment element) is a control block…. See z/OS Security Server RACF Messages and Codes for more information about message IRR421I.” Detecting page 1)
wherein a security setting includes at least one of a privilege and an authorization. (“This vulnerability in combination with a vulnerability associated with improper privilege management (e.g., CWE 269) can cause privilege escalation or improper grant of privilege to an unauthorized user.” Bishop col. 7, ln. 28.)
As to claims 11 and 18 Bishop in view of Detecting and ACEE discloses the method/machine/CRM of claims 10 and 17, and further discloses:
wherein the system control block includes one or more security settings for at least one of a user, job, or environment, wherein a security setting includes at least one of a privilege and an authorization. (“This vulnerability in combination with a vulnerability associated with improper privilege management (e.g., CWE 269) can cause privilege escalation or improper grant of privilege to an unauthorized user.” Bishop col. 7, ln. 28.)
As to claims 6 and 13, Bishop in view of Detecting and ACEE discloses the method/machine/CRM of claims 4, 10, and 16 and further discloses:
wherein the system control block is one of an accessor environment element (ACEE) and a job step control block (JSCB).
(“An application running in an authorized state can make modifications directly to the ACEE in storage after its creation. Such a modification would be outside the involvement of the security product, and the application must take caution to ensure that such updates do not interfere with normal system processing….
When the ACEECHK class is active and RACLISTed, RACF command and authorization processing will detect certain changes made to the ACEE that affect authorization. When a modification is detected, RACF issues message IRR421I to the security console. IRR421I contains information to possibly help you determine whether the modification is expected.” Detecting p. 1)
As to claims 8 and 15, Bishop in view of Detecting and ACEE discloses the method/machine/CRM of claims 7, 14, and 16 and further discloses:
wherein the system control block architecture includes a control block chain (see ACEE Table 1 showing a plurality of offsets) defined by pointers (“2. If you use ACEEIEP, it must point to an area of storage you obtained using a GETMAIN from within the RACINIT post-processing exit…. b. ACEEIEP contains a pointer,” ACEE p. 2) and offsets. (see ACEE Table 1 showing a plurality of offsets).
As to claims 7, 14, and 20, Bishop in view of Detecting and ACEE discloses the method/machine/CRM of claims 4, 10, and 16 and further discloses:
wherein the static code analysis includes: identifying a system control block architecture of an operating system; and determining, based on the system control block architecture, whether one or more processor instructions modifies a particular system control block field. (note Applicant’s specification ¶ 11)
(“An application running in an authorized state can make modifications directly to the ACEE in storage after its creation. Such a modification would be outside the involvement of the security product, and the application must take caution to ensure that such updates do not interfere with normal system processing….
When the ACEECHK class is active and RACLISTed, RACF command and authorization processing will detect certain changes made to the ACEE that affect authorization. When a modification is detected, RACF issues message IRR421I to the security console. IRR421I contains information to possibly help you determine whether the modification is expected.” Detecting p. 1)
As to claims 12, and 19, Bishop in view of Detecting and ACEE the method/machine/CRM of claims 4, 11, and 18, and further discloses:
wherein a security interface is provided for changing the one or more security settings, and wherein the modification of the system control block bypasses the security interface.
(“In combination, however, an attacker to exploit a weakness in a low-privilege-level module to cause damage in a high-privilege-level module, to cause an unauthorized change to the software or any output produced by the software.” Bishop col. 7, ln. 55. Different modules running in different settings.)
(as to claim 19) and wherein the security interface is a Resource Access Control Facility (RACF) (“When the ACEECHK class is active and RACLISTed, RACF command and authorization processing will detect certain changes made to the ACEE that affect authorization. When a modification is detected, RACF issues message IRR421I to the security console. IRR421I contains information to possibly help you determine whether the modification is expected.” Detecting p. 1) in Z/OS. (“The ACEE (accessor environment element) is a control block…. See z/OS Security Server RACF Messages and Codes for more information about message IRR421I.” Detecting page 1)
Claim(s) 3 and 21 is/are rejected under 35 U.S.C. 103 as being unpatentable over Bishop et al., US 9,798,884 (published 2017), in view of Detecting ACEE modifications, hereafter referred to as Detecting, (published 2021-05), ACEE: Accessor Environment Element, hereafter referred to as ACEE (published 2021-04) and McClure et al., US 2013/0212682 (published 2013).
As to claim 3, Bishop in view of Detecting and ACEE discloses the method/machine/CRM of claims 2 but does not explicitly disclose:
wherein the authorized program is one of an AC(1) program, a supervisor call (SVC) routine, and a program call (PC) routine.
McClure discloses:
wherein the authorized program is one of an AC(1) program, a supervisor call (SVC) routine, and a program call (PC) routine.
(“Exemplary embodiments are configured to aid in the detection of security vulnerabilities in z/OS.RTM. authorized programs, primarily supervisor call (SVC), and program call (PC) routines.” McClure ¶ 18. “The computer provides predefined input parameters of test cases for execution by each of the supervisor call routines and the program call routines in order to generate an output for analysis. The computer analyzes the output to determine when at least one of the supervisor call routines and the program call routines performed a potential vulnerability action.” McClure ¶ 5. “the software application 70 on the computer system/server 12 is configured to analyze a list of supervisor call routines (in the SVC table 81) and a list of program call routines (in the PC table 83) of the system code 75 to extract the supervisor call routines 80 (out of the table 81) and the program call routines 82 (out of the table 83) that are available to the unauthorized program.” McClure ¶ 66).
A person of ordinary skill in the art before the effective filing date of the claimed invention would have included the SVC/PC routines of McClure in the code to be analyzed by static/dynamic analysis of Bishop. It would have been obvious to a person of ordinary skill to include the teachings of McClure in the analysis system of Bishop in order to detect vulnerabilities or malicious actors in the “z/OS.RTM” system; thereby incorporating known defect checking of McClure in the vulnerability notification of Bishop.
As to claim 21, Bishop in view of Detecting and ACEE discloses the method/machine/CRM of claims 10 but does not explicitly disclose:
wherein the system control block is a job step control block.
McClure discloses: wherein the system control block is a job step control block.
(“The output 315 of the authorized program is displayed in FIG. 3 to be analyzed by the software application 70 during the post processing phase. The output 315 for analysis includes the storage memory 28, the log record 90, the program status word 335 (the PSW key and state), the program key mask 340, and the job step control block (JSCB, which is relevant to APF authorization) 345.
During the post processing phase, the software application 70 is configured to analyze the output 315 to determine if the test case 72 was able to cause the authorized program 310 (e.g., SVC routine 80 or PC routine 82) to perform one or more operations that the caller program (which is the same as the unauthorized program in PSW key 8-15) is not authorized to perform.” McClure ¶¶ 53-54).
A person of ordinary skill in the art before the effective filing date of the claimed invention would have job step control block of McClure in the segments to be analyzed by static/dynamic analysis of Bishop. It would have been obvious to a person of ordinary skill to include the teachings of McClure in the analysis system of Bishop in order to detect vulnerabilities or malicious actors in the “z/OS.RTM” system; thereby incorporating known defect checking of McClure in the vulnerability notification of Bishop.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. See PTO-892, particularly:
Upton et al., US 2022/0368695, discussing ACEE modifications.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MICHAEL W CHAO whose telephone number is (571)272-5165. The examiner can normally be reached M, W-F 8-5.
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, Rupal Dharia can be reached at (571) 272-3880. 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.
/MICHAEL W CHAO/ Primary Examiner, Art Unit 2492