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 7/21/2025. Claims 1-20 are pending. Claims 1 (a machine), 8 (a method), and 15 (a non-transitory CRM) are independent.
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-20 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Independent claims 1, 8, and 15 each require: “the application identity account being associated with a software application rather than a human user”.
Conversely, Applicant’s specification provides:
¶ 39: “Automated agents, scripts, playback software, devices, and the like running or otherwise serving on behalf of one or more humans may also have accounts, e.g., application identity accounts…. Use of a de facto application identity account by a human is typically limited to (re)configuring the account or to similar administrative or security use.”
As an Application identity account may be used by users, it is unclear how it differs from a user account. More specifically, it is unclear what is required of the claim limitations “the application identity account being associated with a software application rather than a human user”.
Claim Rejections - 35 USC § 102
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-5, 7-12, and 14-20 is/are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Zimmermann et al., US 2018/0027006 (published 2018).
As to claims 1, 8, and 15 Zimmermann discloses a machine/method/CRM comprising:
A computing system for credential-based anomaly detection in application identity accounts, comprising:
a digital memory configured to store sign-in data representing authentication attempts involving an application identity account, (“The analysis mode for the detection of an unusual activity use case may include detecting logins from unusual locations and logins at unusual hours or days of week scenarios or login from unusual devices, in discrete processing (such as by a policy engine), after a baseline is computed.” Zimmermann ¶ 286. See also ¶ 280. Accounts being the attributes of the login entity: “A compromised account use case may be based on access location and times. A compromised account use case may include scenarios. Scenarios may include a Login to an account during predefined hours (for example at night) and days (for example on weekends), a login from an unknown device” Zimmermann ¶ 264)
the application identity account being associated with a software application rather than a human user; (“Anomaly detection activities 640 may detect behavioral patterns that may be abnormal related to a baseline. … anomaly may be defined, either by threshold-based rules, by statistical analysis, or by machine learning on patterns of usage of accounts, users, applications or the like.” Zimmermann ¶ 194)
a processor operatively coupled to the digital memory, the processor configured to:
(a) collect sign-in data over a plurality of time intervals for the application identity account; (“The time window for an unusual activity use case may include a baseline time window of at least three months of data and a detection timeline that may be an ongoing/real-time activity trace.” Zimmermann ¶ 283)
(b) extract a plurality of data features from the sign-in data; and (“Event log data for an unusual activity use case may include activity and login tracing, with location or ip address data as well as information about the device that has been used (type, managed or unmanned, etc. . . . ) or the program that initiated the activity.” Zimmermann ¶ 281)
(c) for a credential used with the application identity account:
(i) aggregate the extracted data features across the plurality of time intervals to generate a credential-specific feature behavior log; and (“Setting a baseline for the detection of unusual activity scenarios may be determined by historical activity patterns. …. A location and time/day baseline may include a very simple model, which may keep a set of all locations for user from a specified number of times, days and months. If new access outside of this set is detected an event may be flagged.” Zimmermann ¶ 285)
(ii) construct a credential history profile characterizing temporal patterns of the data features associated with that credential; and (“Events may be saved only in ninetieth percentile, for example, and events may be flagged if a new event is detected outside of a radius from known set, known time or known day. Detection of unusual activity pattern scenarios may include activity pattern baselines. Activity pattern baselines may include basic patterns, for example patterns that include only the actions performed by a user. Activity pattern baselines may also include resources being accessed, such as action targets.” Zimmermann ¶ 285.)
a machine learning model, trained on previously observed credential history profiles, configured to:
(a) receive as input a current credential history profile; and (“the 6500 may use the data collected from various platforms to profile an organization (and its users) based on behavior over a time period (such as a few months), to define a baseline profile for that organization and its users, using machine learning. From that point on, the machine learning capability of the platform 6500 can observe changes in the pattern of usage from the baseline,” Zimmermann ¶ 557. Current history matching: “A time window for a malicious activity use case scenario may include a time window of hours, a time window of days and the like.” Zimmermann ¶ 292. “above the average for five minute windows over the last three hour window.” Zimmermann ¶ 180)
(b) output an anomaly score indicating a likelihood that the credential is being used in a manner inconsistent with historical behavioral patterns; and (“various metrics about the application, such as an overall score (e.g., a risk score, or a trust rating) for the application, or a score for particular attributes of the application (such as the reputation of its vendor, the level of risk of creating a data breach, the level of risk of enabling a hacker to exploit a vulnerability, or the like)” Zimmermann ¶ 426. “an algorithm may be developed, taking into account all of these factors, to provide an overall risk score for the application, and/or a set of component scores relating to particular types of risk. This algorithm may be improved over time, such as by a machine learning facility” Zimmermann ¶ 436. See also ¶¶ 447, 453. “scores for various applications or the component factors can be used for benchmarking purposes, such as to help an enterprise understand a level of risk relative to other similar enterprises with respect to use of a particular application, a class of applications, or applications in general” Zimmermann ¶ 426)
wherein the processor is further configured to take a security enforcement action based on the anomaly score. (“This allows an IDaaS or other such system to augment access controls based on the risk score, such as to step up authentication when the risk score exceeds a threshold.” Zimmermann ¶ 558)
As to claims 2, 9, 16, Zimmermann discloses the machine/method/CRM of claims 1, 8, and 15 and further discloses:
wherein the plurality of data features comprises one or more of: an IP subnet, a credential type, a hosted IP status, a credential identifier, a user agent, and a resource access identifier. (“IP addresses of known location that are used to access applications” Zimmermann ¶ 425. “by training a machine learning facility to recognize and classify addresses as being associated with an application” Zimmermann ¶ 431. “The report can also show the most risky applications and users, with specific IP addresses for the users, so that the enterprise can intervene, such as by educating the users, blocking the access to the particular applications,” Zimmermann ¶ 447. “Activity pattern baselines may also include resources being accessed, such as action targets.” Zimmermann ¶ 285)
As to claims 3, 10, and 17, Zimmermann discloses the machine/method/CRM of claims 1, 8, and 15 and further discloses:
wherein the security enforcement action comprises one of:
an increased amount of logging;
an alert to administrators or security personnel; or (“Protection may include tracking and reporting on events occurring within PaaS/IaaS environments 138, tracking and reporting on user behavior, and various remediation actions, such as sending alerts, changing access control privileges, blocking or suspending access, and the like, including any of the remediation actions mentioned throughout this disclosure.” Zimmermann ¶ 486)
a recommendation of replacement of a compromised credential.
As to claims 4, 11, 18, Zimmermann discloses the machine/method/CRM of claims 1, 8, and 15 and further discloses:
further comprising a compromise assessment based upon the anomaly score, wherein the compromise assessment is used by an access control mechanism to perform the security enforcement action. (“This allows an IDaaS or other such system to augment access controls based on the risk score, such as to step up authentication when the risk score exceeds a threshold.” Zimmermann ¶ 558)
As to claims 5, 12, and 19, Zimmermann discloses the machine/method/CRM of claims 4, 11, and 18 and further discloses:
wherein the processor is further configured to formulate the compromise assessment at least in part by applying one or more heuristic rules to perform one or both of:
modify the anomaly score during computation of the compromise assessment; or (“Other inputs 2918 may also be provided, such as ratings or scores from third party sources, which can contribute to the risk rating 2930. Information from the attributes of the application can also contribute to the score; for example, applications in the social networking category that access user contact data might generally be considered riskier than productivity applications provided by major enterprise software vendors, or vice versa. As another example, information from a third party system like Checkpoint™ which discovers cloud applications, can be used to enrich data about an application.” Zimmermann ¶ 435)
supersede the anomaly score during computation of the compromise assessment. (“FIG. 39 shows an example of a report 3902 that provides a breakdown of the cloud applications used by an enterprise according to levels of risk. … The probability or predictive score may be useful in situations where incomplete information is available” Zimmermann ¶ 447)
As to claims 7, 14, and 20, Zimmermann discloses the machine/method/CRM of claims 1, 8, and 15 and further discloses:
wherein the processor is further configured to train the machine learning model using one or more of:
sign-in data that is specific to the application identity account; (“the 6500 may use the data collected from various platforms to profile an organization (and its users) based on behavior over a time period (such as a few months), to define a baseline profile for that organization and its users, using machine learning. From that point on, the machine learning capability of the platform 6500 can observe changes in the pattern of usage from the baseline,” Zimmermann ¶ 557)
sign-in data that is specific to a tenant that includes the application identity account;
sign-in data that is specific to a multi-tenant application program that includes the application identity account; or
sign-in data that has an age greater than a specified age, and not less than the specified age. (“For example, detection of statistical anomalies over some aggregates may detect user login between 2:00 am and 3:00 am, where the 1 hour bucket may be more than two standard deviations below average in login activity for that user across last three months.” Zimmermann ¶ 180)
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) 6 and 13 is/are rejected under 35 U.S.C. 103 as being unpatentable over Zimmermann et al., US 2018/0027006 (published 2018), in view of Ginter et al., US 2002/0112171 (published 2002).
As to claims 6 and 13, Zimmermann discloses the machine/method/CRM of claims 1, 8, and 15 and further discloses:
wherein one or both of the anomaly score or the compromise assessment are specific to the credential of the application identity account (“Anomaly detection activities 640 may detect behavioral patterns that may be abnormal related to a baseline. … anomaly may be defined, either by threshold-based rules, by statistical analysis, or by machine learning on patterns of usage of accounts, users, applications or the like.” Zimmermann ¶ 194)
Zimmermann does not disclose that the application identity account comprises multiple credentials, as claimed:
instead of to the application identity account.
Ginter discloses:
instead of to the application identity account.
(“More than one certificate based on different keys may be issued for sites and/or users so that if a given certification key is compromised, one or more “backup” certificates may be used. If a certification key is compromised, A VDE administrator may refuse to authenticate based on certificates generated with such a key, and send a signal after authenticating with a “backup” certificate that invalidates all use of the compromised key and all certificates associated with it in further interactions with VDE participants. A new one or more “backup” certificates and keys way be created and sent to the authenticated site/user after such a compromise.” Ginter ¶ 1553).
A person of ordinary skill in the art before the effective filing date of the claimed invention would have combined Zimmermann with Ginter by providing multiple credentials to an account/entity. 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 Zimmermann with Ginter in order to allow authentication and recovery from compromised credentials, Ginter ¶ 1553, Zimmermann ¶ 263.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. See PTO-892, particularly:
Kolman et al., US 10,003,607, disclosing detecting session based anomalies using machine learning.
Motsinger et al., US 2005/0188222, discloses monitoring user login activity for a server application.
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
Prosecution Insights