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 .
Information Disclosure Statement
The information disclosure statement (IDS) submitted on 02/28/2025 appears that it is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claim(s) 1-8 and 11 is/are rejected under 35 U.S.C. 103 as being unpatentable over BHATNAGAR (US 20110258012 A1), hereafter BHATNAGAR, in view of SVETOV (US 20110283281 A1), hereafter SVETOV.
BHATNAGAR demonstrates, in regard to claim 1: A system for supporting setting of authorities to be granted to roles in a workflow (BHATNAGAR [0051] “The rules that govern what subsets of the task hierarchy appear to each user are organized in a mapping between the overall task hierarchy and the role hierarchy.”), task information for managing a position corresponding to each of tasks in the workflow (BHATNAGAR [0051] “3. Different users see different subsets of the tasks in a particular work-item's (i.e. loan's) activities--different subsets at each level in the hierarchy…The rules that govern what subsets of the task hierarchy appear to each user are organized in a mapping between the overall task hierarchy and the role hierarchy.” The task information for managing a position corresponding to each of tasks in the workflow is provided in this example, by the task hierarchy information of a task.); relationship management information for managing a relationship among nodes, authority types, and the tasks (BHATNAGAR [0040] “Workflow is manifested in the UI in several important ways. To start, each user upon login sees a screen similar to the one shown in FIG. 1 but with a layout and content (pods as well as functions within pods) that are specific to his role.”, [0051] “3. Different users see different subsets of the tasks in a particular work-item's (i.e. loan's) activities--different subsets at each level in the hierarchy…The rules that govern what subsets of the task hierarchy appear to each user are organized in a mapping between the overall task hierarchy and the role hierarchy.”, [0154] “The underlined Actions do not appear in John's screen depicted in FIG. 2 because John is of user role "Processor", which would never have need to execute or even view status of those Activities.” The relationship management information for managing a relationship among nodes (user interface), authority types (access privileges dependent on the role of the user), and the tasks (the tasks themselves) is mapped to the rules.); and conversion information for managing a relationship between the authority types and a display method for each of the nodes, and wherein the processor is, in a display of a first workflow, configured to: determine a position of the each of the nodes by referring to the relationship management information and the task information; determine a display method for the each of the nodes by referring to the relationship management information and the conversion information(BHATNAGAR [0051] “3. Different users see different subsets of the tasks in a particular work-item's (i.e. loan's) activities--different subsets at each level in the hierarchy. For example, a loan officer might see all steps at the top level and down to the third level in his primary ("Application") top-level task but only down to the second level under the other top-level tasks. A processor might only see the "Processing" and "Underwriting" top-level tasks but see down to the third level under both of those. The rules that govern what subsets of the task hierarchy appear to each user are organized in a mapping between the overall task hierarchy and the role hierarchy.”, [0040] “Workflow is manifested in the UI in several important ways. To start, each user upon login sees a screen similar to the one shown in FIG. 1 but with a layout and content (pods as well as functions within pods) that are specific to his role. The example screen in FIG. 1 shows five pods 10a-e. The user may personalize the layout and content within limits defined by his role.”, BHATNAGAR’s governed subsets of the task hierarchy appearing to the user are provide for conversion information as it manages a relationship between the authority type(role) and display method of the node (the display implementations for the UI). ); display the each of the nodes at the determined position corresponding to one of the tasks based on the determined display method representing the authority type(BHATNAGAR [0051] “3. Different users see different subsets of the tasks in a particular work-item's (i.e. loan's) activities--different subsets at each level in the hierarchy. For example, a loan officer might see all steps at the top level and down to the third level in his primary ("Application") top-level task but only down to the second level under the other top-level tasks. A processor might only see the "Processing" and "Underwriting" top-level tasks but see down to the third level under both of those. The rules that govern what subsets of the task hierarchy appear to each user are organized in a mapping between the overall task hierarchy and the role hierarchy.” The displayed node is mapped to the displayed UI for the user, where the determined display method representing the authority type(role) is mapped to the determined display implementations for the UI.); and change a display method for a first node in response to changing the authority type of the first node (BHATNAGAR [0041] “The Activity Plan 10b gives the user a snapshot of the activities related to a particular work-item (loan), some of which are the user's own responsibility and some of which are assigned to other users. The Activity Plan 10b is shown in greater detail in FIG. 2. For the example in FIG. 2, the user currently logged in is John Smith. John Smith may carry out the activities within any column 20a-e in which his name appears in a workgroup 25a-e above the column. Other users, e.g., Mary Jones, who also appear in a column's workgroup 25c-d may also carry out the activities in the column 20c-d.”, [0051] “3. Different users see different subsets of the tasks in a particular work-item's (i.e. loan's) activities--different subsets at each level in the hierarchy.”).
Further regarding claim 1, BHATNAGAR teaches the limitations previously demonstrated, however does not appear to explicitly teach the following limitations demonstrated by SVETOV:
the system comprising: a storage device; and a processor, wherein the storage device stores (SVETOV [0014] “A system and method is provided for providing complex access control in workflows. The system comprises a computer, including a computer readable storage medium and processor operating thereon.”):
a user operation of changing the authority type (SVETOV [0014] “Additionally, the system comprises a configurable matrix of access controls that is used to control access to the plurality of tasks based on the plurality of logical roles.”)
Since BHATNAGAR and SVETOV are from the same field of endeavor as both are directed to role-based workflow management, which is within the same field of endeavor as the claimed invention, it would have been obvious to one of ordinary skilled in the art before the effective filing date of the claimed invention to modify and combine the teachings of BHATNAGAR and SVETOV by incorporating the teachings of SVETOV into BHATNAGAR. The motivation to combine is to improve access control within workflows. (BHATNAGAR [AB]; SVETOV [AB]). This motivation is equally applicable for rejections hereafter.
BHATNAGAR-SVETOV demonstrates, in regard to claim 2: The system according to claim 1, wherein the task information manages the position corresponding to the each of the tasks on a first axis which is linear (SVETOV See FIG. 3 Vertical “Content” column, as the different content types demonstrate each of a different task type across a linear axis, similarly to applicant’s FIG 1. Item 111 horizontal task axis, see further [0043] “The graph 110 has a linear horizontal axis 111 indicating tasks… and a linear vertical axis 112 indicating authorities…”), and wherein the display method for the each of the nodes indicates a position on a second axis which intersects the first axis and which is linear (SVETOV [0014] “The system further comprises a plurality of logical roles. Each logical role defines a responsibility based on the task state and a member of that logical role. Additionally, the system comprises a configurable matrix of access controls that is used to control access to the plurality of tasks based on the plurality of logical roles.”, SEE SVETOV’s FIG. 2 “Display configurable Matrix” 210 and FIG. 3 see top row of graph, a linear horizontal axis of user role types, which intersects with the axis of content types to demonstrate each access level, or display method.).
BHATNAGAR-SVETOV demonstrates, in regard to claim 3: The system according to claim 2, wherein the processor is configured to: change a display position of the first node on the second axis in response to an operation of moving the first node along the second axis by a user, and update the relationship management information based on an authority type corresponding to the changed display position of the first node(SVETOV [0027] “Configurable matrix 210 shows content rules C1-C5 versus roles R1-R5. Each role can be an RBAC role or logical roles related to a user's responsibility or status. Initially, the matrix can be displayed with a default set of access controls which can be configured previously by the user or come standard with the workflow manager. The user can configure access controls using the configurable matrix. As the workflow manager receives each selection 212, the configurable matrix can be updated to reflect the change. Once the user has finished configuring the access controls, access controls for the task are updated based on the selections 214.”).
BHATNAGAR-SVETOV demonstrates, in regard to claim 4: The system according to claim 2, wherein the first axis and the second axis are perpendicular (See SVETOV’s FIG. 2 and FIG 3., both demonstrating perpendicular relationship between both axes.).
BHATNAGAR-SVETOV demonstrates, in regard to claim 5: The system according to claim 1, wherein the processor is configured to display an edge which connects nodes that are adjacent in an execution order of the tasks in the first workflow (BHATNAGAR ’s FIG. 1 displays an edge (vertical scrolling axis) connecting nodes (links to activities for the loans) that are adjacent in an execution order of the tasks (sorted by most urgent loans) in the first workflow (main queue.).).
BHATNAGAR-SVETOV demonstrates, in regard to claim 6: The system according to claim 1, wherein the first workflow shows authority types of an individual workflow of one role selected from a plurality of roles(SVETOV’s FIG. 3 demonstrates authority types of an individual workflow of ADMIN role, for example), wherein the relationship management information manages a relationship among the selected one role, the nodes, the authority types, and the tasks(BHATNAGAR [0013] “In the preferred embodiment, each activity, work-item, user, event and role has associated rules” The relationship management information(rules) manage a relationship between the selected one role(role entry), the nodes (work item displayed on the UI), the authority types(access privileges of the role), and the tasks(the executed task).), wherein the storage device stores role information for managing a position corresponding to each of the plurality of roles(BHATNAGAR [0051] “3. Different users see different subsets of the tasks in a particular work-item's (i.e. loan's) activities--different subsets at each level in the hierarchy… The rules that govern what subsets of the task hierarchy appear to each user are organized in a mapping between the overall task hierarchy and the role hierarchy.”), and wherein the processor is configured to: display an overall workflow including nodes indicating authority types for tasks in each of the plurality of roles(See SVETOV’s FIG. 3, where the overall workflow (workflow column) includes nodes indicating authority types(specified privileges of [0055]) for tasks in each of the plurality of roles (tasks for each role).); determine positions of the nodes in the overall workflow by referring to the role information, the task information, and the relationship management information (SVETOV’s position of the toggled markers within FIG. 2 item 212 are mapped to determined positions of the nodes in the overall workflow, as they reference the specified privileges (role information), content rules (task information), and the access control configuration (relationship management information).); and display, in the overall workflow, nodes having different authority types by using different appearances(SVETOV’s FIG. 5’s workflow displays nodes having different authority types by using different appearances by use of the presence or absence of checkmark.).
BHATNAGAR-SVETOV demonstrates, in regard to claim 7: The system according to claim 6, wherein the processor is configured to indicate, in the overall workflow, one authority type designated in advance, and to display an edge which connects nodes that are adjacent in an execution order of the tasks (BHATNAGAR ’s FIG. 1 displays an edge(vertical scrolling axis) connecting nodes (links to activities for the loans) that are adjacent in an execution order of the tasks(sorted by most urgent loans) in the first workflow(main queue.).).
BHATNAGAR-SVETOV demonstrates, in regard to claim 8: The system according to claim 1, wherein the processor is configured to: transmit a request for approval of a change in the authority type of the first node to an approver terminal; and update, when an approval response from the approver terminal is received, the relationship management information in accordance with the change in the authority type of the first node(SVETOV [0026] “A user using client system 200 can configure access controls for tasks by accessing 202 a workflow manager 204. The workflow manager can present a graphical user interface (GUI) 206 to the user. The user can then navigate the GUI and send a request to configure access controls. When the workflow manager receives the request 208, it can display a configurable matrix 210. Multiple matrices can be presented for different task controls. For example, a matrix of task content controls, or a matrix of task content action controls.”, [0024] “In accordance with an embodiment, configuration of the access controls can be based on external or internal events, or workflow task specific data. For example, approval of a human workflow task can be withheld until task specific data, e.g., documentation indicating that a supervisor has signed off on the task, is attached to the task.”).
Regarding claim 11, claim 11 recites substantially similar limitations as claim 1, but for recitation in the form of a method. Thus, claim 11 is rejected for similar reasoning and rationale as claim 1. BHATNAGAR-SVETOV further teaches a method (SVETOV [0008] “The invention is generally related to workflows and workflow tasks, and particularly to a system and method for providing complex access control in workflows.”).
Claim(s) 9-10 is/are rejected under 35 U.S.C. 103 as being unpatentable over BHATNAGAR-SVETOV, in further view of KUMAR (US 20240137368 A1), hereafter KUMAR.
BHATNAGAR-SVETOV demonstrates, in regard to claim 9: The system according to claim 1, wherein the processor is configured to display a node of a task which matches a search word that has been input (BHATNAGAR ’s FIG. 1 demonstrates a “Find” button with a text input, interpreted by the examiner to be used as input to produce the sorted links to activities (node of a task) by “Most Urgent Loan”, which match the “Find” query and are then sorted.).
Further regarding claim 9, BHATNAGAR teaches the limitations previously demonstrated, however does not appear to explicitly teach the following limitations demonstrated by KUMAR:
to highlight (KUMAR “In at least some embodiments, the user identifier of the user making the request is presented in a distinguishable manner (e.g., bold, highlighted, blinking, etc.), so that said user is easily identifiable from the listing of user identifiers.”)
Since BHATNAGAR-SVETOV and KUMAR are from the same field of endeavor as both are directed to role-based workflow management, which is within the same field of endeavor as the claimed invention, it would have been obvious to one of ordinary skilled in the art before the effective filing date of the claimed invention to modify and combine the teachings of BHATNAGAR-SVETOV and KUMAR by incorporating the teachings of KUMAR into BHATNAGAR-SVETOV. The motivation to combine is to improve role-based access control within workflows. (BHATNAGAR [AB]; SVETOV [AB]; KUMAR [AB]). This motivation is equally applicable for rejections hereafter.
BHATNAGAR-SVETOV demonstrates, in regard to claim 10: The system according to claim 9, wherein the processor is configured to change, in response to a user operation of changing the authority type of one node among nodes of a plurality of tasks which match the search word (KUMAR “In at least some embodiments, device field 334 includes a search field to enable the user to search for a target device(s) to which privileged access is being requested. In at least some embodiments, the search field is a search bar, wherein in response to user inputs of “device type”, “vendor/service provider”, “service”, “domain” (e.g.—RAN, Core, etc.), “location type” (e.g.—Country, Prefecture, State, City, etc.), “location name” (e.g.—Japan, Osaka, etc.), a keyword, or any other information associated with the information of the target device(s) device field 334 is updated to show only device identifiers partially or fully matching the inputted keyword. In at least some embodiments, the available device identifiers (e.g., all device identifiers of the network or device identifiers match the inputted keyword) are presented in a first portion of device field 334, and selected (via double-click, drag and drop, etc.)”), the authority types of all of the nodes of the plurality of tasks to the same authority type (SVETOV [0027] “The user can configure access controls using the configurable matrix. As the workflow manager receives each selection 212, the configurable matrix can be updated to reflect the change. Once the user has finished configuring the access controls, access controls for the task are updated based on the selections 214.”, The authority type of the nodes of the plurality of task is mapped to the specified privileges of the specific task content within the tasks, and is configured (changed) by the user. The user is able to toggle each privilege to the same value, or change the authority types of all the nodes of the plurality of tasks to the same authority type.).
Conclusion
The prior art made of record and not relied upon is considered pertinent to the applicant’s disclosure:
US 20210081897 A1; Culver; Andrew discloses a method for enabling collaboration between individuals to design, construct and maintain a building. The method comprises providing a network based computer system including at least one server and multiple clients. The multiple clients allow respective individuals to interact with the server. The server includes a machine-readable storage, which is encoded with software for execution by a CPU for allowing individuals at the respective clients to create, execute and manage projects associated with at least one of a design phase, construction phase and maintenance phase of the building. Each project comprises one or more events that are related to time. The method also comprises storing in the machine-readable storage events as they occur during execution of each project to create a building project database spanning at least the design phase and the construction phase and optionally the maintenance phase of the building. [AB]
US 20200202301 A1; CHEN; Dazhi discloses a method for setting approval roles at workflow approval nodes based on form fields is disclosed in the present invention, including: setting a system organization structure; and selecting one of a role attribute field, a department attribute field or a submission role of the approval process in a form as a level subject; after selecting the level subject, determining a level by using the selected subject as a judgment criterion; and filling in a specific level value. In the present invention, according to requirements, the role attribute field, the department attribute field or the submission role involved in the form may be used as a criterion for determining a department level. If a signing role in a contract form is selected as a level subject, the signing role (rather than a submission role by default all the time) is used as a criterion for determining a level, so as to determine an approval role of an approval node. The method is more flexible and convenient in use, and high in universality. A system provides a specified group to approve an approval request submitted by a top-level department supervisor, thereby avoiding the problem that the top-level department supervisor cannot complete an approval process by means of level approval. [AB]
US 20170277900 A1; TONG; Yao discloses a method and device for access control. The method includes: when a group of tasks are executed, controlling an access of a subject to an object according to operation permission corresponding to each of the tasks in the group of tasks. The device comprises a control component arranged to, when a group of tasks are executed, control an access of a subject to an object according to operation permission corresponding to each of the tasks in the group of tasks.
US 20150281287 A1; GILL; Jasvir Singh discloses solutions for role-based, rules-driven access enforcement, the techniques including active policy enforcement. Techniques address blended risk assessment and security across logical systems, IT applications, databases, physical systems, and operational technology systems in the context of threat and fraud detection, risk analysis and remediation, active policy enforcement and continuous monitoring. Further, techniques provide out of the box workflow rules that give the ability to add, modify, or delete the applicability parameters for policy enforcement. [AB]
US 20140082689 A1; Christiaens; Gregory discloses a user interface is displayed to an administrator (or other user) and allows the administrator to walk through a workflow performed by a user in a given role. Data access steps performed in walking through the workflow are recorded and a set of permissions is identified, based upon the recorded workflow. The set of permissions corresponds to the role. [AB]
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Kamryn Gillespie whose telephone number is 703-756-5498. The examiner can normally be reached on Monday through Thursday from 9am to 6pm.
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, Linglan Edwards can be reached on (571) 270-5440. 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.
/K.J.G./Examiner, Art Unit 2408
/LINGLAN EDWARDS/Supervisory Patent Examiner, Art Unit 2408
Prosecution Insights