Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
This action is in response to the amendment filed 1/22/2026. Claims 1-20 are pending. Claims 1 (a machine), 10 (a method), and 19 (a machine) are independent.
Response to Arguments
The § 101 rejection of claims 1-9 is withdrawn due to the addition of the physical element ‘memory’ in claim 1.
Applicant’s arguments, see pages 11-12, filed 1/22/2026, with respect to the rejection(s) of claim(s) 1, 2, 5, 9, and 10 under Torman (US 2014/0006441) have been fully considered and are persuasive. Torman does not disclose comparing permission lists and updating a list based thereupon. Therefore, the rejection has been withdrawn. However, upon further consideration, a new ground(s) of rejection is made in view of Torman et al., US 2014/0006441 (filed 2013), in view of Wongkar et al., US 2016/0043999 (filed 2015).
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 1-20 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Claims 1, 10, and 19 require:
“resource-type elements describing resources…
wherein the database is configured to store a respective resource-type element for each resource of the plurality of resources”
It is unclear what “store a respective resource-type element for each resource” requires beyond “resource-type elements describing resources”. Specifically, the database does not store resources; the database only stores “resource-types”. It is unclear what “for each resource” requires when the claim does not itself require resources. For the purposes of examination, “resource-type element for each resource” will be interpreted to mean ‘store respective resource-type elements describing resources’.
Dependent claims 2-9, 11-18, and 20 are rejected due to their dependency on claims 1, 10, and 19, respectively.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claim(s) 1, 2, 5, 9, 10, and 16-19, is/are rejected under 35 U.S.C. 103 as being unpatentable over Torman et al., US 2014/0006441 (filed 2013), in view of Wongkar et al., US 2016/0043999 (filed 2015).
As to claims 1, 10 and 19, Torman discloses a machine/method/machine comprising:
An access-management system for managing access to a plurality of resources, the access-management system comprising:
a database configured to store resource-type elements describing resources, (“Permissions may include an indication of access, and/or type of access, to a particular computing resource such as a component of a system.” Torman ¶ 89. “a custom metadata entity is a metadata component that is created and customized by a developer for use in a multitenant database environment.” Torman ¶ 108. See Figures 7, 10, and 14, showing various resource types; i.e. custom metadata classes.)
permission-type elements describing permissions related to said resources, (“For example, permission 1 may provide read access to a field of a database table. Permission 2 may provide access to a certain software program. Permission 5 may provide write capability to a particular field of a database table. Finally, permission 6 may provide access to a particular object.” Torman ¶ 90)
and user type-elements describing permissions of users, (See Torman Fig. 5 showing user profiles, Fig. 6 showing permission sets, each assigned to users: “users 520 and 525 may be assigned profile 505 a” Torman ¶¶ 91 and 95. “A permission set, as described above, may be associated with a user, and the permission set defines one or more permissions indicating accessibility of components of the multitenant database environment” Torman ¶ 116. “FIG. 5 shows a graphical representation of permission assignments to users using profiles” Torman ¶ 89. “Thus, users may receive permission to access certain resources. A permission server in an on-demand database service environment can store criteria data regarding the types of users and permission sets to assign to each other. For example, a computing device can provide to the server data indicating an attribute of a user (e.g., geographic location, industry, role, level of experience, etc.) and particular permissions to be assigned to the users fitting the attributes.” Torman ¶ 25).
Wherein the database is configured to store a respective resource-type element for each resource of the plurality of resources; (“Permissions may include an indication of access, and/or type of access, to a particular computing resource such as a component of a system.” Torman ¶ 89. “a custom metadata entity is a metadata component that is created and customized by a developer for use in a multitenant database environment.” Torman ¶ 108. See Figures 7, 10, and 14, showing various resource types; i.e. custom metadata classes.)
At least one memory (Torman ¶ 35)
an access manager including
a processor coupled to the at least one memory and configured to implement a plurality of resource-provisioning software components; (“system 16 includes application servers configured to implement and execute CRM software applications as well as provide related data, code, forms, web pages and other information to and from user systems 12 and to store to, and retrieve from, a database system related data, objects, and Webpage content.” Torman ¶ 42)
wherein each resource-provisioning software component of the plurality of resource-provisioning software components is configured to execute a respective resource-provisioning task in relation to a respective resource manager of a respective resource of the plurality of resources (Note that these elements are illustrated as elements in Applicant’s figure 1, ostensibly a multi-server system. “Environment 10 may include user systems 12, network 14, database system 16,” Torman ¶ 36. See Torman Figure 2, illustrating a plurality of Application servers hosting databases, with a plurality of tenant processes thereupon.)
using a respective application programming interface (API) of the respective resource manager by: (“an Application Programming Interface (API) is configured to expose a collection of permissions” Torman ¶ 26, “permission server 405 may receive the criteria via an application programming interface (API).” Torman ¶ 88. See also Figure 2, API 32)
Torman, while disclosing distributing permissions (Figure 4 and associated disclosure) does not explicitly disclose:
obtaining from the respective resource manager a first list of users and permissions relative to the respective resource;
obtaining from the database a second list of users and permissions relative to the respective resource;
comparing the first list to the second list; and
based on differences between the first list and the second list, configuring the respective resource with the respective resource manager based on the permissions of the second list.
Wongkar discloses:
resource-provisioning software components, resource-provisioning task, (“A system implementing the invention disclosed herein may operate to compare the TTS of the permission tree with the TTS of a corresponding master tree.” Wongkar ¶ 49)
resource manager (“Whenever a cache is accessed” Wongkar ¶ 49)
obtaining from the respective resource manager (See Wongkar Fig. 2 Server 220a-c…n) a first list of users and permissions relative to the respective resource; (“52 Whenever a cache is accessed, for instance, in response to a request from a user, there can be a need to update a permission tree associated with the user.” Wongkar ¶ 49)
obtaining from the database a second list of users and permissions relative to the respective resource; (“A system implementing the invention disclosed herein may operate to compare the T.sub.TS of the permission tree with the T.sub.TS of a corresponding master tree.” Wongkar ¶ 49, the master tree residing in the database 240 of Wongkar Fig. 2)
comparing the first list to the second list; and (“The permission tree may be considered “dirty” if the master tree has a temporally more recent T.sub.TS. This temporal difference can be an indication that some portion of the permission tree must be rebuilt” Wongkar ¶ 49)
based on differences between the first list and the second list, configuring the respective resource with the respective resource manager based on the permissions of the second list. (“In one embodiment, flow 900 may comprise updating the TreeTimestamp and the NodeTimestamp of the dirty node (step 902) to reflect the time the node was reconstructed (block 818).” Wongkar ¶ 57)
A person of ordinary skill in the art before the effective filing date of the claimed invention would have combined Torman with Wongkar by utilizing the permission tree update mechanism of Wongkar to implement the database permissions of Torman. It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to combine Torman with Wongkar in order to optimize the process of updating user access permissions across large user/resource/permission groups, thereby avoiding downtime and saving processing capabilities, Wongkar ¶ 4.
As to claim 2, Torman in view of Wongkar discloses the machine of claim 1 and further discloses:
wherein the database further stores user-profile-type elements, wherein each user-profile type element defining one or more permissions, and wherein at least part of a user type elements is assigned to one or more user profiles. (“Thus, users may receive permission to access certain resources. A permission server in an on-demand database service environment can store criteria data regarding the types of users and permission sets to assign to each other. For example, a computing device can provide to the server data indicating an attribute of a user (e.g., geographic location, industry, role, level of experience, etc.) and particular permissions to be assigned to the users fitting the attributes. Permission sets meeting the criteria may be selected and assigned to the users. Moreover, permissions may appear in multiple permission sets. In this way, the users can gain access to the components of a system.” Torman ¶ 25)
As to claims 5 and 17, Torman in view of Wongkar discloses the machine/method of claims 1 and 10 and further discloses:
The system according to claim 1, wherein, in the database, each element includes information describing the element based on a data structure that is specific to a type of the element and comprises a predefined list of description objects.
(Per MPEP 2111.03: “The transitional term “comprising”, which is synonymous with “including,” “containing,” or “characterized by,” is inclusive or open-ended and does not exclude additional, unrecited elements or method steps.” Thus, the claimed “predefined list” does not exclude additional elements. Instead this only requires that some data, for a data type, is predefined; which is presumed by the description of the data itself as detailed in Torman Fig. 7. Note permission database of Torman Fig. 4, and of Wongkar as combined in claim 1.)
As to claims 9 and 18, Torman discloses the machine/method of claims 1 and 10 and further discloses:
further comprising a visualization system configured to generate representations of relations between elements of the database, via a graphical user interface.
(See Torman Fig. 14. “FIG. 10, an example of the association database table 1000 with a number of association records is displayed. … In some implementations, the association database table may include the entity type, e.g. ApexPage and ApexClass, of all of the custom metadata entities represented in the association database table, so that an administrator of the system may conveniently identify the various types of metadata entities that are presently assigned to permission sets in the system.” Torman ¶ 120)
As to claim 16, Torman in view of Wongkar discloses the machine of claim 10 and further discloses:
storing, in the database, user-profile-type elements, wherein each user-profile-type element defines one or more permissions, and wherein at least part of a user-type element is assigned to one or more user profiles. (See Torman Fig. 5 showing user profiles, Fig. 6 showing permission sets, each assigned to users: “users 520 and 525 may be assigned profile 505 a” Torman ¶¶ 91 and 95. See also claim 2 above.)
Claim(s) 3, 4, 7, 11, 12, 14, and 20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Torman et al., US 2014/0006441 (filed 2013), in view of Wongkar et al., US 2016/0043999 (filed 2015), and Bitting et al., US 2011/0246527 (filed 2011).
As to claims 3, 11, and 20, Torman in view of Wongkar discloses the machine of claim 1 but does not disclose:
wherein, in response to a user type element related to a new user, assigned to at least one permission related to a given resource, being added to the database, a corresponding resource provisioning software component is configured to configure the at least one permission related to the given resource for the new user with the resource manager of the given resource.
Bitting discloses:
wherein, in response to a user type element related to a new user, assigned to at least one permission related to a given resource, being added to the database, (new profiles/permissions: “a new entity (e.g., a permission set, etc.) may be introduced and used to store parent related permission information. This object may have a relationship to either a user or profile.” Bitting ¶ 51. “the additional permissions may increase the access to one or more elements of the system that was provided by the profile. In still another embodiment, the additional permissions may reduce the access to one or more elements of the system that was provided by the profile. Of course, however, the additional permissions may not affect the access provided by the profile.” Bitting ¶ 29. new entity and Figure 5 new user.)
a corresponding resource provisioning software component is configured to configure the at least one permission related to the given resource for the new user with the resource manager of the given resource.
(“A cleanup script may be run during the down window to capture those profiles that changed after the initial iteration. It may be ensured that this is one of the later scripts run in the down window to ensure that any scripts run during the down window against core profile don't come along behind this and update the permission information for a given profile.” Bitting ¶ 56. See also Bitting ¶ 90)
A person of ordinary skill in the art before the effective filing date of the claimed invention would have combined Torman in view of Wongkar with Bitting by providing for permission modifications and associated updates in the database. It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to combine Torman in view of Wongkar with Bitting in order to create and update varying degrees of permissions for different users as new permissioning needs arise, thereby improving access management and auditability.
As to claims 4 and 12, Torman discloses the machine/method of claims 1 and 10 and further discloses:
In response to a user type element, assigned to one or more permissions related to given resources, is deleted from the database, (“an assignment of a permission set may be removed or revoked from a user. For example, as discussed above, user 625 may be assigned permission sets 605 (i.e., a permission set associated with “engineers”) and 610 (i.e., a permission set associated with “California”). If user 625 transfers from California to Alabama, a system administrator may desire to revoke the assignment of permission set 610 to user 625.” Torman ¶ 100)
Torman in view of Wongkar does not explicitly disclose:
each corresponding resource provisioning software component is configured to delete permissions stored by the resource manager.
Bitting discloses:
(“the permission set may include a negative permission. For example, the permission set may remove or limit access to particular data within the system (e.g., restrict access to an API only which disallows a user from accessing the user interface, etc.).” Bitting ¶ 30. See also ¶¶ 43)
each corresponding resource provisioning software component is configured to delete permissions stored by the resource manager.
(“A cleanup script may be run during the down window to capture those profiles that changed after the initial iteration. It may be ensured that this is one of the later scripts run in the down window to ensure that any scripts run during the down window against core profile don't come along behind this and update the permission information for a given profile.” Bitting ¶ 56. See also Bitting ¶ 90)
A person of ordinary skill in the art before the effective filing date of the claimed invention would have combined Torman in view of Wongkar with Bitting by providing for permission modifications and associated updates in the database. It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to combine Torman in view of Wongkar with Bitting in order to create and update varying degrees of permissions for different users as new permissioning needs arise, thereby improving access management and auditability.
As to claims 7 and 14, Torman in view of Wongkar discloses the machine/method of claims 1 and 10 but does not disclose:
The system according to any of claim 1, further including comprising: a ticketing system having an operator interface through which an operator performs an action from the group including adding, deleting, or modifying a user-type element in the database, wherein the ticketing system is configured to generate a ticket for the action performed; and
a database management system configured to updatethe database based on the generated ticket.
Bitting discloses:
a ticketing system having an operator interface through which an operator performs an action (see Bitting figures 4 and 5 showing administrator workflows) from the group including adding, deleting, or modifying a user-type element in the database, wherein the ticketing system is configured to generate a ticket for the action performed; and (“the additional permissions may increase the access to one or more elements of the system that was provided by the profile. In still another embodiment, the additional permissions may reduce the access to one or more elements of the system that was provided by the profile. Of course, however, the additional permissions may not affect the access provided by the profile.” Bitting ¶ 29. “associating the permission set may include assigning the one or more additional permissions associated with the permission set to the one or more users.” Bitting ¶ 31.)
a database management system configured to updatethe database based on the generated ticket.
(“A cleanup script may be run during the down window to capture those profiles that changed after the initial iteration. It may be ensured that this is one of the later scripts run in the down window to ensure that any scripts run during the down window against core profile don't come along behind this and update the permission information for a given profile.” Bitting ¶ 56. See also Bitting ¶ 90)
A person of ordinary skill in the art before the effective filing date of the claimed invention would have combined Torman in view of Wongkar with Bitting by providing for permission modifications and associated updates in the database. It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to combine Torman in view of Wongkar with Bitting in order to create and update varying degrees of permissions for different users as new permissioning needs arise, thereby improving access management and auditability.
Claim(s) 6 and 13 is/are rejected under 35 U.S.C. 103 as being unpatentable over Torman et al., US 2014/0006441 (filed 2013), in view of in view of Wongkar et al., US 2016/0043999 (filed 2015), and Morrison et al., US 2003/0182319 (filed 2002).
As to claims 6 and 13, Torman in view of Wongkar discloses the machine/method of claims 1 and 10 and further discloses:
The system according to claim 1, a workflow automation software component executed by the processor, the workflow automation software component configured to automatically execute a workflow including the execution of each of the resource-provisioning software components (“Environment 10 may include user systems 12, network 14, database system 16,” Torman ¶ 36. See Torman Figure 2, illustrating a plurality of Application servers hosting databases, with a plurality of tenant processes thereupon.) related to the resources listed in the database, (the workflow being the updating of the permissions: “52 Whenever a cache is accessed, for instance, in response to a request from a user, there can be a need to update a permission tree associated with the user.” Wongkar ¶ 49)
Torman in view of Wongkar does not explicitly disclose:
Wherein the workflow automation software component is configured to periodically execute the workflow
Morrison discloses:
Wherein the workflow automation software component is configured to periodically execute the workflow
(“In an asynchronous replication system, an apply program 50 will extract the updates from the staging table 49 periodically, and propagate the updates to the remote sites 40a-40c, thereby updating the replicas 25a-25c therein.” Morrison ¶ 5)
A person of ordinary skill in the art before the effective filing date of the claimed invention would have combined Torman in view of Wongkar with Morrison by utilizing the perioding synchronization mechanism of Morrison to propagate permission updates of Torman to the respective client devices. It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to combine Torman in view of Wongkar with Morrison in order to maintain consistency of the permissions of Torman, thereby achieving the expected permission decision outcomes.
Claim(s) 8 is/are rejected under 35 U.S.C. 103 as being unpatentable over Torman et al., US 2014/0006441 (filed 2013), in view of in view of Wongkar et al., US 2016/0043999 (filed 2015), Morrison et al., US 2003/0182319 (filed 2002) and Cooper et al., US 2010/0174863 (filed 2010).
As to claim 8, Torman in view of Wongkar and Morrison discloses the machine/method of claim 6 but does not disclose:
The system according to claim 1, wherein the workflow automation software component is configured to execute the workflow each time the database is updated.
Cooper discloses:
wherein the workflow automation software component is configured to execute the workflow each time the database is updated.
(“Clients who use the system 100 to store data may expect updates to individual records to be applied in a consistent order at all replicas. Since the system 100 uses asynchronous replication, updates will not be seen immediately everywhere, but each record retrieved will reflect a consistent version of the record. As such, the system 100 achieves per-record, eventual consistency without sacrificing fast writes in the common case. The system 100 may not require a separate record locking mechanism to maintain data consistency, such as a lock server, lease server or master directory. Instead, the system 100 may serialize all updates to a record, by assigning each update a sequence number.” Cooper ¶ 24).
A person of ordinary skill in the art before the effective filing date of the claimed invention would have combined Torman in view of Wongkar and Morrison with Cooper by utilizing the serialized update of Cooper to propagate permission updates of Torman to the respective client devices. It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to combine Torman in view of Wongkar and Morrison with Cooper in order to maintain consistency of the permissions of Torman, thereby achieving the expected permission decision outcomes.
Claim(s) 15 is/are rejected under 35 U.S.C. 103 as being unpatentable over Torman et al., US 2014/0006441 (filed 2013), in view of in view of Wongkar et al., US 2016/0043999 (filed 2015), and Cooper et al., US 2010/0174863 (filed 2010).
As to claim 15, Torman in view of Wongkar discloses the machine/method of claims 10 but does not disclose:
further comprising executing the plurality of resource provisioning tasks each time the database is updated.
Cooper discloses:
further comprising executing the plurality of resource provisioning tasks each time the database is updated.
(“Clients who use the system 100 to store data may expect updates to individual records to be applied in a consistent order at all replicas. Since the system 100 uses asynchronous replication, updates will not be seen immediately everywhere, but each record retrieved will reflect a consistent version of the record. As such, the system 100 achieves per-record, eventual consistency without sacrificing fast writes in the common case. The system 100 may not require a separate record locking mechanism to maintain data consistency, such as a lock server, lease server or master directory. Instead, the system 100 may serialize all updates to a record, by assigning each update a sequence number.” Cooper ¶ 24).
A person of ordinary skill in the art before the effective filing date of the claimed invention would have combined Torman in view of Wongkar with Cooper by utilizing the serialized update of Cooper to propagate permission updates of Torman to the respective client devices. It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to combine Torman in view of Wongkar with Cooper in order to maintain consistency of the permissions of Torman, thereby achieving the expected permission decision outcomes.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. See PTO-892, particularly:
Wijayaratne et al., US 2014/0149461, discloses permission database synchronizing.
Savage et al., US 2016/0065672, discloses synchronization of permissioned content in cloud environments.
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 MICHAEL W CHAO whose telephone number is (571)272-5165. The examiner can normally be reached M, W-F 8-5.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Rupal Dharia can be reached at (571) 272-3880. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/MICHAEL W CHAO/ Primary Examiner, Art Unit 2492