DETAILED ACTION
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
This office action is in response to communication filed on 05/30/2025.
Status of claims in the instant application:
Claims 1-12 are pending.
Priority
This application is a CON of 17/663,996 filed on 05/18/2022 now PAT US 12353579 B2, which claims benefit of 63/201,958 filed on 05/20/2021.
Information Disclosure Statement
Information Disclosure Statements (IDS) filed on 06/27/2025, 07/02/2025, 10/07/2025, 02/17/2026 and 07/13/2026 have been considered, and a signed copies of the IDS forms have been attached to this office action.
Drawings
Drawings filed on 05/30/2025 have been inspected, and it’s in compliance with MPEP 608.02.
Specification
Specification filed on 05/30/2025 has been inspected and it’s in compliance with MPEP 608.01.
Double Patenting
The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory double patenting rejection is appropriate where the conflicting claims are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on nonstatutory double patenting provided the reference application or patent either is shown to be commonly owned with the examined application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. See MPEP § 717.02 for applications subject to examination under the first inventor to file provisions of the AIA as explained in MPEP § 2159. See MPEP § 2146 et seq. for applications not subject to examination under the first inventor to file provisions of the AIA . A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b).
The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The filing date of the application in which the form is filed determines what form (e.g., PTO/SB/25, PTO/SB/26, PTO/AIA /25, or PTO/AIA /26) should be used. A web-based eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about eTerminal Disclaimers, refer to www.uspto.gov/patents/process/file/efs/guidance/eTD-info-I.jsp.
Claims 1-12 are rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1-16 of U.S. Patent No. US 12353579 B2 in view of Pat. No.: US 10867291 B1.
Instant Application
Reference Patent (US 12353579 B2)
1. A computer-implemented method for providing purpose-based checkpoints on user actions, the computer-implemented method comprising, by one or more hardware processors executing program instructions: receiving, from a first user, a request to perform an action; determining any checkpoint config objects associated with the action; causing display of a checkpoint dialog based on a checkpoint config object; receiving a user input via the checkpoint dialog; determining whether criteria associated with the checkpoint config object are satisfied based on the user input; and in response to determining that the criteria associated with the checkpoint config object are satisfied: generating a checkpoint record object including a status of pending approval; and generating a notification to a second user requesting approval for the first user to perform the action.
6. The computer-implemented method of claim 5, wherein the checkpoint dialog comprises at least one of: a request for an acknowledgement, a request for a selection from a dropdown, or a request for a written response.
1. A computer-implemented method for providing purpose-based checkpoints on user actions, the computer-implemented method comprising, by one or more hardware processors executing program instructions: receiving, from a user, a request to perform an action; determining a checkpoint config object associated with the action, wherein the checkpoint config object includes criteria including at least one of: a required acknowledgement, a required selection from a dropdown, or a required written response; causing display of a checkpoint dialog based on the checkpoint config object, wherein the checkpoint dialog comprises at least one of: a request for the required acknowledgement, a request for the required selection from a dropdown, or a request for the required written response; receiving a user input via the checkpoint dialog; determining, based on the user input, whether the criteria of the checkpoint config object are satisfied; and in response to determining that the criteria of the checkpoint config object are satisfied: generating a checkpoint record object; storing information indicative of the user input in the checkpoint record object; and proceeding to perform the action.
4. The computer-implemented method of claim 3, wherein the user input comprises at least one of: an acknowledgement, a selection from a dropdown, or a written response.
4. The computer-implemented method of claim 1, wherein the user input comprises at least one of: an acknowledgement, a selection from a dropdown, or a written response.
5. The computer-implemented method of claim 4 further comprising, by the one or more hardware processors executing program instructions: in response to determining that the criteria associated with the checkpoint config object are not satisfied: denying the request to perform the action.
5. The computer-implemented method of claim 1 further comprising, by the one or more hardware processors executing program instructions: in response to determining that the criteria of with the checkpoint config object are not satisfied: denying the request to perform the action.
7. The computer-implemented method of claim 6, wherein said causing display of the checkpoint dialog comprises: providing instructions to a user device to display the checkpoint dialog.
2. The computer-implemented method of claim 1, wherein said causing display of the checkpoint dialog comprises: providing instructions to a user device to display the checkpoint dialog.
8. The computer-implemented method of claim 7, wherein the instructions comprise at least one of: a title, a description, or a prompt.
3. The computer-implemented method of claim 2, wherein the instructions comprise at least one of: a title, a description, or a prompt.
9. The computer-implemented method of claim 1, wherein the checkpoint config object comprises at least one of: a checkpoint type, or one or more conditions.
8. The computer-implemented method of claim 1, wherein the checkpoint config object comprises at least one of: a checkpoint type, or one or more conditions.
10. The computer-implemented method of claim 9, wherein said determining any checkpoint config objects associated with the action comprises: determining whether a checkpoint type, or one or more conditions, associated with the checkpoint config object are satisfied.
9. The computer-implemented method of claim 1, wherein said determining any checkpoint config objects associated with the action comprises: determining whether a checkpoint type, or one or more conditions, associated with checkpoint config objects are satisfied.
11. A system comprising: one or more computer-readable storage mediums storing program instructions; and one or more processors configured to execute the program instructions to cause the system to perform the computer-implemented method of claim 1.
10. A system comprising: a computer readable storage medium having program instructions embodied therewith; and one or more processors configured to execute the program instructions to cause the system to perform the computer-implemented method of claim 1.
However the claims of the reference patent “US 12353579 B2” does not contain the limitation of, “generating a notification to a second user requesting approval for the first user to perform the action”. But it would have been obvious to seek approval of a request for an action by an user/requestor when the requestor does not have the proper authority to perform the action and that the approver can either approve or deny the request remotely to help expedite the process and that the analogous art (Yien, Abstract, Col.2,Ln.22-62) discloses such features.
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 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.
Claims 1-12 are rejected under 35 U.S.C. 103 as being unpatentable over Pub. No.: US 20170093867 A1 to Burns et al. (hereinafter “Burns”) in view of Pub. No.: US 20200077136 A1 to KWATRA et al. (hereinafter “KWATRA”), and further in view of Pat. No.: US 10867291 B1 to Yien et al. (hereinafter “Yien”)
Regarding Claim 1. Burns discloses A computer-implemented method for providing purpose-based checkpoints on user actions (Burns, Abstract, Claim 1: … A computer-implemented method for rule-based access control …), the computer-implemented method comprising, by one or more hardware processors executing program instructions (Burns, Para [0068]: … Processors suitable for the execution of a computer program include, by way of example, both general and special purpose microprocessors, and any one or more processors of any kind of digital computer. Generally, a processor will receive instructions and data from a read-only memory or a random access memory or both. The essential elements of a computer are a processor for performing actions in accordance with instructions and one or more memory devices for storing instructions and data ….):
receiving, from a first user, a request to perform an action (Burns, Para [0024, 0048], FIG. 2: … When a user such as the user 119 requests to access the server system 122 or perform an action with respect to stored data accessible through the server system 122, from the user interface 124 on the user's client device 120, the user's request is first sent to the security engine 112 …);
determining any checkpoint config objects associated with the action (Burns, Para [0026-0027, 0048], FIG. 2: … Rules can be pre-defined by server system 122, for example, server system 122 can apply a set of global rules at a particular checkpoint to all users. As used herein, a “checkpoint” refers to a defined point or discrete event at which an activity can occur, such as logging into the server system 122, previewing a file, uploading a file, downloading a file, creating a shared link to a file, and so on … The user's activity and/or information associated with the user/device can be evaluated by application 125 or security engine 112 to determine, for example, if the device is trusted, or if there are anomalies or other issues (206), by providing user and session information to the security engine 112 through an API (208). The security engine 112, based on the user and session information, accesses the rules database 134 and actions database 132 (210) for rules applicable to the checkpoint (212) … Rule actions can be different for different user groups (e.g., enterprises, companies or affiliations), given the same rule. For instance, a particular rule (e.g., user device's network connection is from a foreign country) can be mapped to different actions for different user affiliations (e.g., deny access for a user with company A, allow file access for a user with company B, or allow read-only access for a user with no affiliation). Other mappings between a rule and an action are possible. Mappings can be stored (with corresponding actions) in the actions database 132. An action determined by the security engine 112 can be sent back to the user interface 124 (or an original caller application that sent the user's request) where the action is performed. For instance, if a determined action is asking for another set of credentials (e.g., two-factor authentication), the user interface 124 can display a request for the user 119 to answer a security question (e.g., “what is your mother's maiden name?” …);
causing display of a checkpoint dialog based on a checkpoint config object (Burns, Para [0016, 0048-0049], FIG. 2: … the user 119 can access the server system 122 from a user interface 124 of an application 125 executing on the user's client device 120 … The security engine 112 can have a timeout period for determining applicable rules and actions. If the timeout period (e.g., 50 milliseconds) has elapsed, the security engine 112 assumes that no rule is applicable (214), and notifies the application 125 to allow the user to continue, for example, to download a file as requested, e.g., to access the file in the user interface 124 of the application 125 (218) …);
However, Burns does not explicitly teach, but KWATRA from same or similar field of endeavor teaches:
“receiving a user input via the checkpoint dialog (KWATRA, Para [0084-0086]: … If, at step 516, the user accepts the re-rendered media content via a positive confirmation, the re-rendered media content is continued to be displayed by the content-displaying IoT device, and the user information analyzation, method of re-rendering of the media content, and the user's response is recorded within the database 455 to allow the learning of resulting patterns associated with each re-rendering instance. It should be noted that the database 455 is cloud-based such that the resulting patterns and processes of re-rendered media content will be available to any IoT device the user 480 uses in the future for viewing the media content. The method 500 ends (step 520) …)”;
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of KWATRA into the teachings of Burns, because it discloses that, “the media content modification service 402 takes advantage reinforcement machine learning in order to identify personalized suitable timing for any rendered media content, and modifies the visual and audio appeal for such content. The system may consider the following parameters as input features: 1. Biometric data, health data, and mental and emotional state data. 2. Calendar data, including a predicted engagement level of any user. For instance, the calendar data may indicate that within the next day the user 480 has a client presentation, so their attentiveness level will be less towards any presented media content. Because most of the user's concentration will likely be directed toward the client presentation, ameliorative action can be taken/suggested in order to play content of user's choice (e.g., the system may play inspirational or concentration based video/audio/textual content with varying durations in order to compensate for the user's time and cognitive state). 3. User's current level of attention. For instance, if the embedded IoT device detects that guests have arrived at the user's home, the media content may be tailored to be directed toward the focus of the user and the appropriate guests rather than merely the user 480 alone (KWATRA, Para [0087])”.
Burns further discloses:
determining whether criteria associated with the checkpoint config object are satisfied based on the user input (Burns, Para [0048-0049], FIG. 2: … The user's activity and/or information associated with the user/device can be evaluated by application 125 or security engine 112 to determine, for example, if the device is trusted, or if there are anomalies or other issues (206), by providing user and session information to the security engine 112 through an API (208). The security engine 112, based on the user and session information, accesses the rules database 134 and actions database 132 (210) for rules applicable to the checkpoint (212) ….); and
in response to determining that the criteria associated with the checkpoint config object are satisfied (Burns, Para [0048-0049], FIG. 2: … Before the timeout period elapses, if the security engine 112 determines that the user's request results in no applicable rules based on the rule conditions, the security engine 112 can determine that the user's request is acceptable (e.g., not anomalous) (222), and notifies the application 125 to allow the user to continue (216) …):
generating a checkpoint record object including a status of pending approval (Burns, Para [0049], FIG. 2: … The security engine 112 also records the related activities in the events database 136 (226). The security engine 112 notifies the application 125, which in turns carries out the action(s) determined by the security engine 112 (228). If the action is a denial of the user request and is specified as a “silent” action, the application 125 can provide the user (through the user interface 124) an indication of bad request (e.g., without providing specific reasons). The application 125 can also write actions and user activities to the events database 136 (242, 244) or servers of the user's affiliation …); and
However, the combination of Burns-KWATRA does not explicitly teach, but Yien from same or similar field of endeavor teaches:
“generating a notification to a second user requesting approval for the first user to perform the action (Yien, Abstract, Col.2,Ln.22-62: … A point-of-sale application on a worker mobile device can send a request for manager approval to perform a transaction-related action for which a worker lacks sufficient permissions. A manager application on a remote manager device can display a notification of the request and can also present additional information regarding the request (and historical requests), including a queue of pending requests that can be generated and updated according to priority rules and transaction conditions. The manager application receives an indication of the manager's approval to the worker mobile device. In response, the worker mobile device can automatically perform the action … techniques described herein are directed to remote provisioning of manager approval to enable completion of actions pertaining to transactions. For instance, a worker can send a request for approval to perform an action for which the worker has restricted or insufficient permissions. Using techniques described herein, a worker, via a mobile device executing application(s) that restrict the worker's ability to perform the action, can submit a request that a manager approve the action, and the manager can approve the action via a remote device. In an example, the action the worker wishes to perform is an action within a point-of-sale (POS) application that the worker has insufficient permissions in the POS application to perform (e.g., a void, a comp, etc.). Manager approval enables the worker to perform the action by causing an update of the worker's permissions … techniques described herein are directed to sending a notification of the request to a mobile device of the manager and enabling the manager to indicate approval of the request via input to a UI displayed on the mobile device. For instance, a manager can receive a pop-up notification of a request on their mobile phone, and can approve or deny the request by selecting a control that can be displayed as part of the notification …).”
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Yien into the combined teachings of Burns-KWATRA, because it discloses that, “the action the worker wishes to perform is an action within a point-of-sale (POS) application that the worker has insufficient permissions in the POS application to perform (e.g., a void, a comp, etc.). Manager approval enables the worker to perform the action by causing an update of the worker's permissions. For instance, a worker can desire to void an item in an order but may not have permissions to do so. Techniques described herein can facilitate remote provisioning of approval from a manager of the worker thereby enabling the worker to void the item without the manager needing to be present or otherwise effectuating the void (e.g., other than by remotely provisioning approval) … (Yien, Col.2.Ln.35-45)”.
Regarding Claim 2. The combination of Burns-KWATRA-Yien discloses the computer-implemented method of claim 1, Yien further discloses, “further comprising, by the one or more hardware processors executing program instructions:
receiving an input from the second user approving the request (Yien, Abstract, Col.26-27,Ln.63-67, ln-1-26, FIG. 5: … Block 508 illustrates updating the permission level of the worker commensurate with the action either (a) automatically or (b) by input at a mobile device of another worker, based on determining that the current state of the transaction satisfies a condition …);
updating the checkpoint record object including a status of approved (Yien, Abstract, Col.26-27,Ln.63-67, ln-1-26, FIG. 5: … lock 508 illustrates updating the permission level of the worker commensurate with the action either (a) automatically or (b) by input at a mobile device of another worker, based on determining that the current state of the transaction satisfies a condition. In an example in which the state of a transaction satisfies a trigger condition, the manager application can update the worker's permission level to at least a level that allows performance of the action, or similar actions. Further, such permissions can be temporary and/or conditional, for example, valid for a period of time or for a current state of the transaction. In one example, a manager can provide an authorization to update the permission level by responding to a notification of the request for manager approval displayed on mobile manager device …); and
proceeding to perform the action (Yien, Abstract, Col.26-27,Ln.63-67, ln-1-26, FIG. 5: … Block 510 illustrates sending the worker mobile device an indication that the permission level was updated, the transaction being processed by the worker mobile device based on the updated or overridden permission. In some examples, manager application can send an indication of the updated permission level to a POS application of the worker mobile device. The worker mobile device can then enable the action to occur and/or process the transaction …).”
The motivation to further combine Yien remains same as in claim 1.
Regarding Claim 3. The combination of Burns-KWATRA-Yien discloses the computer-implemented method of claim 1, Yien further discloses, “further comprising, by the one or more hardware processors executing program instructions:
receiving an input from the second user rejecting the request (Yien, Abstract, Col.31, Ln.10-52, FIG. 9: … UI 900 is also illustrated as including selectable control 910 (“Deny Comp”). Selection of selectable control 910 indicates a denial of the worker's request. Selection of selectable control 910 can cause the manager application to send an indication of the denial to the worker mobile device, either directly or indirectly …);
updating the checkpoint record object including a status of rejected (Yien, Abstract, Col.31, Ln.10-52, FIG. 9: … Selection of selectable control 910 can leave the permission level and permissions of the worker intact, such that worker is unable to perform the requested action (in UI 900, the requested action is a comp) …); and
denying the request to perform the action (Yien, Abstract, Col.31, Ln.10-52, FIG. 9: … Selection of selectable control 910 can leave the permission level and permissions of the worker intact, such that worker is unable to perform the requested action …).”
The motivation to further combine Yien remains same as in claim 1.
Regarding Claim 4. The combination of Burns-KWATRA-Yien discloses the computer-implemented method of claim 3, Burns further discloses, “wherein the user input comprises at least one of: an acknowledgement, a selection from a dropdown, or a written response (Burns, Para [0047]: … If the security engine 112 determines that applicable rules result in no corresponding action, the security engine 112 can hand off the user's access request to the appropriate functional component, such as file downloader 118 or file uploader 114 for downloading or uploading files from or to the server system 122, respectively. The security engineer 112, the file uploader 114, and the file downloader 118 can store the history of the user's request and subsequent actions (taken by the user or the server system 112) in the events database 136 …)”.
Regarding Claim 5. The combination of Burns-KWATRA-Yien discloses the computer-implemented method of claim 4, Burns further discloses, “further comprising, by the one or more hardware processors executing program instructions:
in response to determining that the criteria associated with the checkpoint config object are not satisfied (Burns, Para [0048-0049]: … FIG. 2 is a data flow diagram of an example method for determining if an action requested to be taken at a particular checkpoint is permitted, restricted, malicious or otherwise anomalous. In FIG. 2, when the user 119 accesses the server system 122 (202), the application first authenticates the user, for example, by providing credentials provided by the user to an authentication server of the server system 122 and receives an confirmation (204). The user's activity and/or information associated with the user/device can be evaluated by application 125 or security engine 112 to determine, for example, if the device is trusted, or if there are anomalies or other issues (206), by providing user and session information to the security engine 112 through an API (208). The security engine 112, based on the user and session information, accesses the rules database 134 and actions database 132 (210) for rules applicable to the checkpoint (212). The security engine 112 can have a timeout period for determining applicable rules and actions … Before the timeout period elapses, if the security engine 112 determines that the user's request results in no applicable rules based on the rule conditions, the security engine 112 can determine that the user's request is acceptable (e.g., not anomalous) (222), and notifies the application 125 to allow the user to continue (216). If the security engine 112 determines that the user's request at the checkpoint results in one or more applicable rules, the security engine 112 can evaluate the rule(s) to determine one or more actions (e.g., allow access, deny access) to perform (224). The security engine 112 also records the related activities in the events database 136 (226) …):
denying the request to perform the action (Burns, Para [0048-0049]: … If the security engine 112 determines that the user's request at the checkpoint results in one or more applicable rules, the security engine 112 can evaluate the rule(s) to determine one or more actions (e.g., allow access, deny access) to perform (224).The security engine 112 notifies the application 125, which in turns carries out the action(s) determined by the security engine 112 (228). If the action is a denial of the user request and is specified as a “silent” action, the application 125 can provide the user (through the user interface 124) an indication of bad request (e.g., without providing specific reasons). The application 125 can also write actions and user activities to the events database 136 (242, 244) or servers of the user's affiliation …).”
Regarding Claim 6. The combination of Burns-KWATRA-Yien discloses the computer-implemented method of claim 5, KWATRA further discloses, “wherein the checkpoint dialog comprises at least one of: a request for an acknowledgement (KWATRA, Para [0084-0085]: … At step 516, the user 480 may then be given an option to accept or reject the re-rendered media content via a positive or negative confirmation. In some embodiments, a positive confirmation may comprise the user 480 performing no action and allowing the re-rendered media content to continue playing. In other embodiments, the positive confirmation may require a physical or virtual confirmation that the user 480 accepts the modified media content. If, at step 516, the user 480 rejects the re-rendered media content (e.g., via input into the content-displaying IoT device), the method 500 returns to re-rendering the media content using alternative visual and/or audio characteristics at step 512 and again alerts the user 480 that the media content has been re-rendered …), a request for a selection from a dropdown, or a request for a written response.”
The motivation to further combine KWATRA remains same as in claim 1.
Regarding Claim 7. The combination of Burns-KWATRA-Yien discloses the computer-implemented method of claim 6, Burns further discloses, “wherein said causing display of the checkpoint dialog comprises:
providing instructions to a user device to display the checkpoint dialog (Burns, Para [0015-0017, 0026]: … An action determined by the security engine 112 can be sent back to the user interface 124 (or an original caller application that sent the user's request) where the action is performed. For instance, if a determined action is asking for another set of credentials (e.g., two-factor authentication), the user interface 124 can display a request for the user 119 to answer a security question (e.g., “what is your mother's maiden name?”) …).”:
Regarding Claim 8. The combination of Burns-KWATRA-Yien discloses the computer-implemented method of claim 7, Burns further discloses, “wherein the instructions comprise at least one of: a title, a description, or a prompt (Burns, Para [0015-0017, 0026]: … An action determined by the security engine 112 can be sent back to the user interface 124 (or an original caller application that sent the user's request) where the action is performed. For instance, if a determined action is asking for another set of credentials (e.g., two-factor authentication), the user interface 124 can display a request for the user 119 to answer a security question (e.g., “what is your mother's maiden name?”) …)”.
Regarding Claim 9. The combination of Burns-KWATRA-Yien discloses the computer-implemented method of Claim 1, Burns further discloses, “wherein the checkpoint config object comprises at least one of: a checkpoint type, or one or more conditions (Burns, Para [0044]: … The security engine 112 can, using information related to the user, the user's session, and/or the user's device, determine applicable rules, evaluate the rules, and identify a corresponding action(s) for the user's request. Various types of information can be provided as input for the evaluation of a particular rule, including, for example, user agent, IP address, user identifier, identifier for the user's affiliation, user actions (e.g., login, signup, token, preview, download, upload), identifier of the application 125, or identifier of the client device 120, age of the user's account (e.g., accounts older than 60 days can be trusted more than newly created accounts), geolocation (e.g., whether the client device 120 is accessing the server system 122 from a trusted location, such as a geographical area associated with a company location, versus an untrusted location, such as a geolocation known to generate spam accounts, hacking attempts, or other malicious activity), whether the user's device is trusted (e.g., whether the device 120 is logged in through a secure connection, whether the device 120 meets an enterprise security policy, and the like), and whether an action associated with the rule has occurred within a previous period of time (e.g., 3 minutes). Other types of user information for evaluating rules and determining an action are possible …).”
Regarding Claim 10. The combination of Burns-KWATRA-Yien discloses the computer-implemented method of claim 9, Burns further discloses, “wherein said determining any checkpoint config objects associated with the action comprises:
determining whether a checkpoint type, or one or more conditions, associated with the checkpoint config object are satisfied (Burns, Para [0051]: … the security engine 112 can use attributes associated with the user and file information (e.g., metadata), and determine an action that allows, denies, or restricts the user's request. For example, the security engine 112 can construct a graph of attributes (e.g., each node corresponding to an attribute). The graph can organize attributes according to a dependency scheme among attributes wherein a given attribute is dependent on one or more other attributes if those other attributes are considered subparts or sub-attributes. For example, a user ID attribute can have child attributes of user name and domain name (for organizations that have multiple domains). Rules having conditions satisfied by attributes along a path in the graph are considered matches and fired to cause performance of one or more actions … )”.
Regarding Claim 11. This claim contains all the same or similar limitations as claim 1, hence similarly rejected as claim 1.
**** Burns also discloses a system (Burns: FIG. 1) computer readable storage medium with instructions and one or more processors executing the instructions to perform the functions (Burns: Para [0063-0065, 0068]).
Regarding Claim 12. This claim contains all the same or similar limitations as claim 1, hence similarly rejected as claim 1.
Burns also discloses a computer readable storage medium with instructions and one or more processors executing the instructions to perform the functions (Burns: Para [0063-0065, 0068]).
Pertinent Prior Arts
The following prior arts made of record and not relied upon are considered pertinent to applicant's disclosure.
US 20200401714 A1; Klein et al.: Klein discloses A method, apparatus, and computer program product for validating a structured data object. A computer system receives a request to access enterprise data within a human resources database. The request is received from a consuming service within an authentication context of the user. The computer system determines a view context for the human resources (HR) database by applying a business rule to the authentication context. The business rule comprises a set of data nodes that are composed into a structured data object according to a domain specific language. The computer system creates a data view of the human resources database according to the view context determined by the business rule. The computer system provides the data view to the consuming service. The consuming service natively accesses the enterprise data through the data view.
The present disclosure relates generally to an improved computer system and, in particular, to a method and apparatus for accessing information in a computer system. Still more particularly, the present disclosure relates to a method, a system, and a computer program product for natively accessing enterprise data according to an identified view context of a user.
US 20200053090 A1; KLIGER et al.: KLIGER discloses Methods, systems, and media are shown for generating access control rules for computer resources involving collecting historical access data for user accesses to a computer resource and separating the historical access data into a training data set and a validation data set. An access control rule is generated for the computer resource based on the properties of the user accesses to the computer resource in the training data set. The rule is validated against the validation data set to determine whether the rule produces a denial rate level is below a threshold when the rule is applied to the validation data set. If the rule is valid, then it is provided to an administrative interface so that an administrator can select the rule for application to incoming user requests.
US 20170351875 A1; Rotem et al.: Rotem discloses A data security system, including a security manager computer making network API calls to a service that performs data-exchange transactions for end users, the API calls remotely controlling the service so that the security manager computer accesses an outgoing transaction that has already entered the cloud-based service, by generating one or more security platform rules that are applied by the service and cause the service to automatically transmit the outgoing transaction to an inspection location prior to transmission of the outgoing transaction to a destination, and a data inspector operative to inspect data of the outgoing transaction in the inspection location for data leakage, wherein the security manager computer further controls the service so as to transmit the outgoing transaction to the destinations when the data inspector clears the data, and to perform a remedial action regarding the outgoing transaction when the data inspector does not clear the data.
US 20110030045 A1; Beauregard et al.: Beauregard discloses methods and system where privileges and access to resources on a per-process basis are controlled, an administrator creates a rule that may be applied to modify a token of a process. The rule may include an application-criterion set and changes to be made to the groups and/or privileges of the token. The rule may be set as a policy within a group policy object (GPO), where a GPO is associated with one or more groups of computers or users. When a GPO containing a rule is applied to a computer, a driver installed on the computer may access the rule(s) anytime a logged-on user executes a process. If the executed process satisfies the criterion set of a rule, the changes contained within the rule are made to the process token, and the user has expanded and/or contracted access and/or privileges for only that process.
The disclosed methods and systems related generally to securing resources and privileges on a computer, and more particularly to controlling access to resources and controlling privileges per process.
US 20040015723 A1; Pham et al.: Pham discloses A network file access appliance that operates as a secure portal for network file access operations between client computer systems and network storage resources. The file access appliance terminates network file access transactions, identified by packet information including client system, mount point, and file request identifiers, between client systems and mount points supported by the access controller. A policy parser determines, based on the packet information, to selectively initiate network file access transactions between the access controller and network storage resources to enable completion of selected network file access transactions directed from the clients to the network file access appliance. The network file access transactions directed to the network storage resources are modified counterparts of policy selected client network file access transactions modified to reference mapped network storage resource mount points and support the secure transfer and storage of network file data.
US 20190332721 A1; Pathiyattuthody et al.: Pathiyattuthody discloses a method for VA based content interaction in electronic device. The method includes displaying a VA application in a first portion and a browsing application in a second portion of the screen of the electronic device. The method also includes receiving at least one user command at the VA application to view a specific content of the browsing application and providing at least one response to the at least one user command by the VA application while dynamically displaying the specific content of the browsing application based on the at least one user command. Further, the method includes automatically creating a milestone index based on the at least one user command, the at least one response by the VA application and a state of the browsing application and displaying the milestone index in a third portion of the screen of the electronic device.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MAHABUB S AHMED whose telephone number is (571)272-0364. The examiner can normally be reached on 9AM-5PM EST M-F.
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, Ali Shayanfar can be reached on 571-270-1050. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
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-free). 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.
/MAHABUB S AHMED/Examiner, Art Unit 2434
/TESHOME HAILU/Primary Examiner, Art Unit 2434
Prosecution Insights