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 .
DETAILED ACTION
Background
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 responsive to the Amendment filed on August 12, 2025.
Claims 1, 6, and 9 are amended. Claims 1, 4-6, and 9 are pending for examination. Claims 1, 6, and 9 are independent claims.
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 of this title, 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, 4, 6, and 9 are rejected under 35 U.S.C. 103 as being unpatentable over Taylor et al., U.S. Patent Application 2009/0070744 A1 (published Mar. 12, 2009) (hereinafter “Taylor”) in view of Parker et al., U.S. Patent 5,729,734 (issued Mar. 17, 1998) (hereinafter “Parker”) and Daily et al., U.S. Patent Publication 2009/0089291 A1 (published Apr. 2, 2009)
Regarding Claim 1, Taylor teaches a method for authorizing operation permissions for a user (see, e.g., Taylor, Abstract and para. 2, describing a business application software method and system that includes access control lists; para. 22, describing controlling access to data in a database that contains data of the system; and paras. 26 and 39, indicating controlling access levels to users of the system), comprising:
generating a single Graphical User Interface (GUI) comprising an input for selecting a form name corresponding to a form (see, e.g., id., para. 14 and Fig. 1A, describing and illustrating a customer relationship management [CRM] system as an example of the business application software system, the CRM system comprising various modules such as contacts, accounts, leads, opportunities, and reports modules; para. 21, describing reports as comprising fields to be displayed; and para. 39 and Fig. 5A, describing and illustrating details of using a security module of the system to manage an access control list and manage which users can view what fields by providing field level access restrictions tied to user roles, illustrating a user interface for managing field permissions tied to contacts [which can be viewed as representing a form as indicated by a selectable Contacts set in the left menu], and illustrating a selectable menu at the left side of the user interface for selecting other sets of field permissions [representing other forms and indicating selection of a form by name]. Note that although the user interface discussed in relationship to Figures 5A-5C can be viewed as a single screen comprising the recited input, a single graphical user interface may comprise multiple screens);
wherein the GUI is configured to display a list of elements of the form corresponding to the selected form name, and the GUI comprises an input for selecting one element item of one of the elements of the form (see, e.g., id., paras. 40 and 41 and Figs. 5A and 5B, illustrating the left-side selectable menu for selecting other sets of field permissions, describing and illustrating functionality to change a cell by clicking, describing and illustrating user interface features for specifying for a particular user role what actions are allowed for a specific field including selection of the specific field causing display of a list of possible permissions, and illustrating selection of a First Name field);
the GUI is further configured to display a system role in a computer management system while the element item is selected, and display a current operation permission status of the system role for the selected element item (see, e.g., id., paras. 40-42 and Figs. 5B and 5C, describing and illustrating a user interface for specifying what actions are allowed for a specific field, illustrating display of a particular user role in the system, and describing and illustrating display of a permission status of Not Set for the First Name field with other possible permissions displayed); and
the GUI further comprises an input for authorizing the selected element item for one or more of the system roles (see, e.g., id., para. 40 and Fig. 5B, describing and illustrating user interface features for selecting from a list of possible permissions including Read/Write, Read/Owner Write, Read Only, and Owner Read/Owner Write [all representing authorizing a selected element for a current user role]; para. 42 and Figs. 5A and 5C, describing and illustrating a user interface of the system after the First Name field and a group of fields grouped with the Last Name field have both been set to None [illustrating changing permission via a user interface]);
wherein types of a form element comprise a form operation permission, a form field, a time-nature field, a form field value, or one or more thereof (see, e.g., id., paras. 40-42 and Figs. 5B and 5C, describing and illustrating a user interface for specifying permissions allowed for specific form fields in a contact editing form [representing form elements including form operation permissions, form fields, and form field values in some sense] and illustrating a birthdate field [representing a time-nature field in some sense]. Note that the teachings anticipate the alternative language of the claim),
wherein each of multiple system roles is an independent object in the system which is not a group or class, one system role is related to a user while the user is capable of being related to the one or more system roles, and the user is configured to obtain the operation permission of the related one or more system roles (see, e.g., id., paras. 39-42 and Figs. 5A-5C, describing field level access restrictions tied to user roles, describing and illustrating a user interface for specifying permissions for specific fields for a particular role, and illustrating viewing and editing permissions for a role labeled “JACOB TEST” [suggesting a role corresponding to a specific user rather than a group or class and indicating a user related to at least one role]; col. 2, lines 9-20, indicating assignment of privileges in relationship to job assignments; and col. 2, lines 33-33, describing individuals granted access to objects by being assigned membership in appropriate roles. Note that teachings indicating assigning privileges in relationship to job assignments, assigning a user a membership in appropriate roles, and a role defined in relationship to a specific user anticipate the language of the claim regarding a user capable of being related to one or more roles related to a selection).
However, although Taylor suggests granting permissions to any user roles and suggests managing multiple users or user roles together (see, e.g., Taylor, paras. 13, 27, 39, and 43), it does not appear to teach the method wherein the GUI is configured to display all system roles in the computer management system after the element item is selected, and display a current operation permission status of each system role for the selected element item.
Parker teaches a method for authorizing operation permissions for a user wherein a GUI is configured to displaying all system roles in a computer management system after an element item is selected, and display a current permission status of each system role for the selected element item (see, e.g., Parker, Abstract, describing a file service administration method; col. 9, lines 16-53, and Fig. 5, describing and illustrating embodiments of a user interface for editing privileges in which an administrator selects an item from a list of items, such as an item labeled “test folder-1” from a list of items contained in “Volume,” in order to set various access privileges for the item; and col. 10, lines 36-50, describing and illustrating the user interface for editing privileges associated with the selected item as comprising a User List icon that causes display of an additional window having a list of all network users from which the administrator may select a user or user group [users or groups representing roles at least in the sense of identities that may be assumed] for which access privileges to the selected item will be granted. Note that a combination of the noted interface features can be viewed as displaying all system users in the system and displaying a current permission status of each system user for the selected element item at least because presence and absence of display in the granted privileges list represent current permission statuses).
Taylor and Parker are analogous art at least because they are from the same field of endeavor as the claimed invention, referencing methods for granting data access to users and with teachings directed to displaying a current permission status. Before the effective filing date, it would have been obvious to a person of ordinary skill in the art to combine the teachings of Taylor and Forster and implement a method in which all system roles in a computer management system are displayed after an element item is selected and a current permission status of each system role for the selected element item is displayed in order to allow more efficient monitoring and management of permissions of multiple users related to a particular item (see, e.g., Parker, col. 1, lines 5-35, col. 2, lines 4-8, col. 3, lines 5-60, and col. 10, lines 37-50; and in view of the value of user list management well known in the art).
However, although Taylor teaches granting permissions to specific user roles (see, e.g., Taylor, paras. 39-42 and Figs. 5A-5C), Taylor as modified by Parker does not appear to explicitly teach the method wherein during a same period, the one system role, when being related to a user, is related to the user only while the user is capable of being related to the one or more system roles.
Daily teaches a method wherein each of multiple system roles is an independent object in a system which is not a group or class, and during a same period, each one of the system roles, when being related to a user, is related to the user only while the user is capable of being related to one or more system roles ([0021] In general, the invention includes a system and method for enabling Roles to be implemented as Entities in a system, independent of Groups and users. As used herein, "Role" includes an Entity in the computing environment composed of a Role owner attribute and one or more capabilities, parameters, and/or attributes that may be applied to the representation of a user in the computing environment. The invention contemplates a Role as an Entity or object in the system that helps to decouple these characteristics from the Group and user Entities. All three of the major Entities in the system (users, Groups, and Roles) may own other Roles. See also [0033]-[0034] Other embodiments could combine this association with the usable_Roles association 235, using a flag in the association to denote whether or not the Role is active.).
Daily is analogous art at least because it is from the same field of endeavor as the claimed invention, referencing methods for granting data access to users and with teachings directed toward roles. Before the effective filing date, it would have been obvious to a person of ordinary skill in the art to combine the teachings of Taylor, Parker, and Daily and implement a method in which each of multiple system roles is an independent object which is not a group or class and in which, during a same period, each one of the system roles, when being related to a user, is related to the user only while the user is capable of being related to one or more system roles in order to enable more flexible and powerful modeling, thereby enabling systems to more accurately reflect real-world organizations and relationships Daily [0021].
Regarding Claim 4, Taylor as modified by Parker and as further modified by Daily teaches the method according to Claim 1, wherein when or after the system role is created, a department is selected for the system role, the system role belongs to the department (see, e.g., Taylor, para. 41, describing embodiments in which record ownership is based on group membership such as a user being a member of particular sales group; para. 43, describing embodiments in which access control lists of the system are used for various purposes such as controlling what fields a user has the ability to modify and describing an example in which only an Auditing or Finance group is allowed to be able to see and edit credit information without having that information shared with other departments [representing permissions based on assignment to groups or departments]; and para. 44, describing an example in which only Sales Operations and Finance can edit portions of a certain record when an opportunity is closed. Organization and corresponding selection such that a user role belongs to a group or department would have been obvious to one of ordinary skill in the art over these teachings in order to accomplish the permission scenarios described), the system role is authorized according to its work content (see, e.g., id., paras. 43 and 44, describing examples in which only an Auditing or Finance group is allowed to be able to see and edit credit information without having that information shared with other departments and in which only Sales Operations and Finance can edit portions of a certain record when an opportunity is closed [representing roles authorized according to work content in some form]), a name of the system role is unique in the department, and a number of the system role is unique in the system (see, e.g., id., paras. 62 and 63, describing embodiments in which functionality provides prefixes to maintain uniqueness of module namespaces such that development and deployments of modules in a collaborative and parallel development environment includes underlying data structures, folders, tables, schemas, directories, objects, and paths such that naming conflicts are avoided and describing embodiments in which a global unified registration service guarantee uniqueness of underlying prefixes to avoid all namespace collisions. In view of these teachings, use of a unique name for a user role in a group or department would have been obvious to one of ordinary skill in the art in order to avoid naming collisions in the department. Similarly, use of prefixes provided by the service to generate a name for a user role that is globally unique would have been obvious to one of ordinary skill in the art in order to avoid naming collisions in the system. And as any text string can be viewed as representing or represented by digital encoding of that string, such a unique name for a user role can be viewed as comprising a number that is unique in the system), and when said user is transferred from a post, the user’s relation to an original system role is canceled, and the user is related to a new system role ([0066] Another useful feature is the ability to activate or deactivate a Role 215. In one embodiment, the capability for multiple Roles allows disabling of a single Role 215 (by the Login-ID or by the RO), while remaining logged in with the remaining Roles. One reason a user may wish to deactivate a Role is because that Role may contain very broad powers. As such, motivation for deactivating that Role ensures that the powers are not exercised by mistake. In another embodiment, Role ownership is also transferred temporarily, e.g. for a limited time.)
Regarding Claim 6, Taylor as modified by Parker and as further modified by Daily teaches a method corresponding to the method of Claim 1. Noting that any form comprising ordered data can be viewed as a list, that any form comprising ordered numerical data (see, e.g., Taylor, para. 52 and Fig. 6F) can be viewed as a statistical list, that selection of an operation permission of a field of a statistical list constitutes an operation permission of a statistical list, and that teachings regarding a statistical list element comprising an operation permission of a statistical list anticipate the alternative language of the claim, the same rationale of rejection provided above is applicable.
Regarding Claim 9, Taylor as modified by Parker and as further modified by Daily teaches a method corresponding to the method of Claim 1. Noting that Parker’s discussion of selection of a User List icon for a particular item that causes display of a list of all network users (see, e.g., Parker, col. 9, lines 16-53, and Fig. 5) can be viewed as selecting a menu, the same rationale of rejection provided above is applicable.
Claim 5 is rejected under 35 U.S.C. 103 as being unpatentable over Taylor in view of Parker and Daily and in further view of Grebenik et al., U.S. Patent Application 2010/0306008 A1 (published Dec. 2, 2010) (hereinafter “Grebenik”).
Taylor as modified by Parker and Daily teaches the method according to Claim 1 as discussed above and further teaches the method wherein after an element item in a type of form element is selected, the GUI is configured to display elements (see, e.g., Taylor, para. 40 and Fig. 5B, describing and illustrating user interface features including displaying a list of possible permissions when a field is selected).
However, Taylor as modified by Parker and Daily is silent regarding the method wherein the GUI is configured to display separately an authorizer who last authorized the selected element item for each system role and time of the authorization.
Grebenik teaches a method wherein a GUI is configured to display separately an authorizer who last authorized a selected element item for each system role and time of the authorization (see, e.g., Grebenik, Abstract, describing an architecture that removes the limitation of a fixed set of roles and scopes and allows more effective permission auditing; para. 31, describing an auditing an auditing component for auditing roles and permissions; para. 40, describing auditing permissions by creating and presenting reports of roles and associated users to corresponding resources; and paras. 6 and 21, describing delegation of roles to other administrators to facilitate scoping and delegation. Display or presentation of authorization times and authorizing roles is obvious over these teachings in order to audit delegation of permission assignments in the system over time).
Grebenik is analogous art at least because it is from the same field of endeavor as the claimed invention, referencing methods organizing data access and with teachings directed toward presenting access information. Before the effective filing date, it would have been obvious to a person of ordinary skill in the art to combine the teachings of Taylor, Parker, Daily, and Grebenik and implement a method in which a GUI is configured to display separately an authorizer who last authorized a selected element item for each system role and a time of an authorization in order to simplify auditing and provide more accurate permission assignments (see, e.g., Grebenik, paras. 1-4, 6, and 19; and in view of the value of audit logs well known in the art).
Response to Arguments
Applicant’s arguments, filed 8/12/2025, with respect to the rejection(s) of claim(s) 1,4-6,9 under 35 USC 103 have been fully considered and are persuasive in view of the amendments. Therefore, the rejection has been withdrawn. However, upon further consideration, a new ground(s) of rejection is made in view of Daily as detailed above.
Conclusion
The following prior art made of record and not relied upon is considered pertinent to Applicant’s disclosure: Ferraiolo et al., A Role-Based Access Control Model and Reference Implementation Within a Corporate Intranet, ACM Transactions on Information and System Security, Vol. 2, No. 1, Pages 34-64 (Feb. 1999), teaching role cardinality as limiting a role to a certain number of employees at any given time and providing examples of multiple roles limited to a cardinality of one; Barkley, John, U.S. Patent 6,088,679 (issued Jul. 11, 2000), teaching workflow management using role-based access control in which a role unique to an activity is created and the role unique to that activity is assigned to the user who performs the activity; Quan et al., U.S. Patent Application 2010/0174560 A1 (published Jul. 8, 2010), teaching embodiments in which multiple roles are roles that can be filled by only one person; Dau et al., U.S. Patent Application 2011/0321154 A1 (published Dec. 29, 2011), teaching a method for generating constraints in an access control system and teaching an example in which there is only one agent or user per role of multiple roles; and Challenger et al., U.S. Patent Application 2016/0217424 A1 (published Jul. 28, 2016), teaching a method for providing a graphical position hierarchy and describing embodiments in which multiple position nodes have only one incumbent.
Note that pinpoint citations to prior art references provided in this action are exemplary and should not be taken as limiting; each of the references as a whole is considered to provide disclosure relevant to the claimed invention and may be relied upon for all that it would have reasonably suggested to one of ordinary skill in the art.
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to RYAN F PITARO whose telephone number is (571)272-4071. The examiner can normally be reached M-F 8am-4pm.
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, John Cottingham can be reached at 5712721400. 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.
/RYAN F PITARO/Supervisory Patent Examiner, Art Unit 2188