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 .
Priority
The present application is based on, and claims priority from JP Application Serial Number 2024-044606, filed Mar. 21, 2024, the disclosure of which is hereby incorporated by reference herein in its entirety.
Information Disclosure Statement
The information disclosure statement (IDS) submitted on 03/17/2025 was filed after the mailing date of the Non-Provisional Patent Application on 03/17/2025. The submission is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
DETAILED ACTION
This Office Action is in response to a Non-Provisional Patent Application received on 03/17/2025. In the application, claims 1-7 have been received for consideration and have been examined.
Specification
Applicant’s submitted specification has been reviewed and found to be in compliance.
Drawings
Applicant’s submitted drawings have been reviewed and found to be in compliance.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1–7 are rejected under 35 U.S.C. § 101 because the claimed invention is directed to a judicial exception—an abstract idea—without reciting additional elements that amount to significantly more than the judicial exception.
Step 1: Statutory category
Claims 1–7 are directed to an “authority management device” comprising a management unit and a controller. Accordingly, the claims fall within the statutory category of a machine.
Step 2A, Prong One: The claims recite an abstract idea
Claim 1 recites, in substance:
Managing identification information for a group of users;
Associating the group identification information with authority information identifying initially established and subsequently invalidated permissions;
Acquiring a request to change the authority information; and
Changing the authority information in response to the request.
These limitations recite the concept of:
Managing and modifying group-based access permissions.
In particular, the claimed operations involve maintaining records identifying groups and their associated permissions, receiving an instruction to modify the permissions, and modifying the corresponding permission records. These operations constitute evaluations and administrative decisions that can be practically performed in the human mind or by a person using pen and paper. For example, an administrator could maintain a written table listing different groups and their permissions, receive an instruction to invalidate a permission, and modify the table accordingly.
The limitations therefore fall within the mental-process grouping of abstract ideas because they encompass observations, evaluations, judgments, and recordkeeping activities that can practically be performed mentally or with pen and paper. See CyberSource Corp. v. Retail Decisions, Inc., 654 F.3d 1366, 1372–73 (Fed. Cir. 2011); Synopsys, Inc. v. Mentor Graphics Corp., 839 F.3d 1138, 1146–47 (Fed. Cir. 2016).
The limitations also concern administering rules governing which groups of users possess authority to access equipment. Thus, they additionally fall within the certain-methods-of-organizing-human-activity grouping, particularly managing interactions between people and following organizational rules or instructions.
The Federal Circuit has similarly recognized that controlling or limiting access to resources based on permission rules is an abstract concept. See Ericsson Inc. v. TCL Communication Technology Holdings Ltd., 955 F.3d 1317, 1326–28 (Fed. Cir. 2020).
Accordingly, claim 1 recites an abstract idea under Step 2A, Prong One.
Dependent claims
Claims 2–7 further recite particular forms of the same abstract permission-management process.
Claim 2 recites that the authority information includes flag information indicating whether an initially established authority is valid or invalid. This limitation merely represents a permission status using a flag or other informational designation. A person maintaining a permission table could similarly mark each authority as “valid” or “invalid.” The limitation therefore remains part of the identified mental process.
Claim 3 recites notifying that the first authority information was changed. Communicating the result of the permission-change process does not alter the character of the underlying abstract idea. A person administering permissions could notify the affected person that the permission was changed.
Claim 4 recites:
Maintaining authority information for a subordinate or “slave” group;
Associating the subordinate group with the first group; and
Changing the subordinate-group authority information according to a change in the first-group authority information.
These limitations recite applying hierarchical permission rules to related organizational groups. An administrator could maintain a written organizational hierarchy and, upon changing a parent group’s permissions, make a corresponding change to the permissions recorded for a subordinate group. The limitations therefore constitute the application of organizational rules and mental evaluations to group-based authority information.
Claim 5 recites notifying that the subordinate-group authority information was changed. As with claim 3, this is merely communicating the result of the abstract permission-management process.
Claim 6 recites dividing the authority information into validity information identifying valid authority and invalidity information identifying invalid authority and changing those categories in response to a request. Categorizing permissions as valid or invalid and updating the respective categories are administrative recordkeeping and mental evaluation activities.
Claim 7 recites deleting, from the validity information, information identifying authority that the change request instructs should be invalidated. This limitation merely specifies a particular recordkeeping operation used to implement the permission decision. Removing a permission from a list of valid permissions can be performed manually by erasing, crossing out, or otherwise removing the corresponding entry from a written record.
Accordingly, claims 2–7 also recite the abstract idea of managing and modifying group-based access permissions.
Step 2A, Prong Two: No integration into a practical application
The claims as a whole do not integrate the identified abstract idea into practical application.
The additional elements of claim 1 are a “management unit,” a “controller,” and unspecified “management target equipment.” The management unit is used to maintain the group and authority information, while the controller is used to acquire a change request and modify the information. These elements merely provide a generic computer environment in which the abstract permission-management process is performed.
The claims do not recite:
A particular computer architecture;
A specific database or memory structure;
A new access-control protocol;
A specific authentication or encryption mechanism;
A particular algorithm for processing or propagating authority changes;
A change to the operation of the management target equipment;
Detection or prevention of a particular computer-security threat; or
An improvement to computer processing, memory operation, network operation, or information security technology.
Instead, the claims use generic computer components as tools for storing permission information, receiving change instructions, updating records, and providing notifications.
The reference to “management target equipment” does not meaningfully limit the abstract idea because the claims do not require the controller to operate the equipment, prevent an attempted access, authenticate a user, or alter the technical operation of the equipment. The equipment merely identifies the technological environment in which the stored permission information may eventually be used. Merely limiting an abstract idea to a particular technological environment does not integrate the exception into a practical application. See Alice Corp. Pty. Ltd. v. CLS Bank International, 573 U.S. 208, 222–23 (2014); Bilski v. Kappos, 561 U.S. 593, 610–11 (2010).
Claims 2, 6, and 7 merely specify how permission information is represented, categorized, and edited. The informational content of a record—such as whether an authority is designated valid or invalid—does not provide technological improvement merely because it is stored electronically.
Claims 3 and 5 merely notify a person or system after the authority information has been changed. The notification does not apply the abstract idea to control the management target equipment or achieve another technological result. It therefore constitutes insignificant post-solution activity.
Claim 4 applies the same abstract permission rules to a subordinate group. Although the claim requires changing the subordinate-group information according to the parent-group change, it does not recite a particular technical mechanism for determining, propagating, or resolving the permission changes. It merely instructs the controller to achieve the desired result.
Thus, claims 1–7 merely implement the abstract idea on generic computer components and do not integrate the abstract idea into a practical application.
Step 2B: No inventive concept
The claims are further evaluated to determine whether any additional element, or combination of elements, amounts to significantly more than the identified abstract idea.
The “management unit” and “controller” are recited only in functional terms and perform the ordinary computer functions of:
Storing and associating information;
Receiving a request;
Changing stored information;
Deleting information; and
Sending a notification.
Using generic computer components to store, retrieve, modify, and communicate information constitutes well-understood, routine, and conventional computer activity. See Alice, 573 U.S. at 225–26; Intellectual Ventures I LLC v. Symantec Corp., 838 F.3d 1307, 1315–19 (Fed. Cir. 2016).
Considering the elements as an ordered combination does not produce a different result. The claims merely direct generic computer components to perform the ordinary sequence of maintaining permission records, receiving a requested change, updating the affected records, optionally propagating the change to a subordinate group, and notifying that the change occurred. The ordered combination does not recite an unconventional arrangement of computer components or a technological procedure that improves the functioning of the computer or other equipment.
The dependent-claim limitations likewise do not supply an inventive concept:
A valid/invalid flag in claim 2 is a conventional way to represent a binary status.
Notifications in claims 3 and 5 are generic communication functions.
Hierarchical propagation in claim 4 applies an abstract organizational rule using generic processing.
Separate valid and invalid categories in claim 6 merely organize stored information.
Deleting an entry in claim 7 is an ordinary data-management operation.
Accordingly, neither the individual additional elements nor their ordered combination amounts to significantly more than the abstract idea.
Conclusion
Claims 1–7 are directed to the abstract idea of managing and modifying group-based access permissions, including recording valid and invalid permissions, applying hierarchical permission rules, updating permission records, and notifying affected parties.
The claims implement abstract idea using only generically recited computer components performing ordinary information-storage, processing, modification, deletion, and communication functions. The claims neither integrate the abstract idea into a practical application nor recite an inventive concept sufficient to transform the abstract idea into patent-eligible subject matter.
Therefore, claims 1–7 are ineligible under 35 U.S.C. § 101.
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-2, and 6-7 are rejected under 35 U.S.C. 103 as being unpatentable over Patrick et al., (US20050097166A1) in view of Simonetti et al., (US20220385668A1).
Regarding claim 1, Patrick discloses:
an authority-management system comprising an administration server, administration console, security control modules, security service modules, storage, and one or more processors. Patrick states that its embodiments can be implemented using a conventional computer or microprocessor. See Patrick ¶¶ 115–119 and 155–160, 169.
The administration server, storage, and associated policy-management components correspond to the claimed management unit, while the computer or microprocessor executing the policy-management functions corresponds to the claimed controller.
Regarding:
“the management unit manages, in linkage with first identification information for identifying a first group to which a user who can access management target equipment … belongs, first authority information representing one or a plurality of kinds of authority initially set for the first group”
Patrick discloses that:
A resource can be a service, function, device, or other programmatically accessible entity;
Authorization policies determine whether a user, role, or group may perform an action or access a resource;
User and group information can be stored and managed in directories and databases;
An authorization policy identifies a resource, an action or role, and a subject comprising one or more users, groups, or roles; and
Groups are associated with policies defining their access rights for particular resources.
See Patrick ¶¶ 41–61, 63–65, and 73–83. In particular, Patrick teaches that the subject field identifies the users or groups to which the policy applies, thereby linking group identification information with authority information identifying permitted actions. Patrick further explains that organizational groups are useful for determining authorization policies and provides an example in which users belonging to the “Tellers” group are granted authority to perform an OpenAccount action on the TellerApp resource. See Patrick ¶¶ 75–83.
Regarding:
“and representing authority invalidated after the initial setting”
Patrick teaches policies containing the policy types GRANT and DENY, where “GRANT permits a specified action” and “DENY revokes it.” See Patrick ¶¶ 73–80. Thus, Patrick represents both authority that is permitted and authority that has been revoked or invalidated.
Patrick also teaches that an administrator can create, modify, and delete user, group, and policy definitions. See Patrick ¶116. The policy tool allows users to create, modify, delete, and query policies, including selecting a policy and editing or deleting the selected policy. See Patrick ¶¶160 and 164.
To the extent Patrick does not expressly disclose retaining the originally allowed and subsequently invalidated authorities in separately identifiable forms, Simonetti discloses that security-policy statements are classified into:
A set of allow-policy statements specifying that members of an identity set are allowed to access system resources; and
A set of deny-policy statements specifying that members of an identity set are denied access to system resources.
Simonetti further discloses an allow list 422 and deny list 424, each of which can be implemented as a list, tree, table, or other data structure. See Simonetti ¶¶95–102.
The combined teachings therefore disclose authority information identifying initially valid permissions and permissions subsequently denied or invalidated.
Regarding:
“acquiring a change request for the first authority information”
Patrick discloses an administration console through which an administrator creates, modifies, and deletes group and policy definitions. See Patrick ¶116. Patrick further discloses a user interface capable of responding to commands from a user or another process, and a policy tool through which selected policies can be edited or deleted. See Patrick ¶¶156, 160, and 164. The user’s selection and command to edit or delete a policy constitutes a change request.
Patrick also discloses that policy and configuration information is transmitted as a provisioning request and that, when a configuration or policy change is made and distributed from the administration console, a security control module receives the change and updates its cached copy. See Patrick ¶¶118–119 and 159.
Regarding:
“changing the first authority information in response to the change request”
Patrick discloses that the selected policy can be edited or deleted using the administration console. Patrick also teaches that the security control module receives a policy change, updates its cached configuration, and propagates the change to a security service module. See Patrick ¶¶159–164.
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to represent Patrick’s GRANT and DENY policies using Simonetti’s separate allow and deny permission sets.
Both references address computer-based administration of user, group, or role permissions for accessing protected resources. Simonetti expressly explains that classifying policies into separate allow and deny sets improves the efficiency of evaluating effective permissions and improves the compactness and readability of the permission representation. See Simonetti ¶¶95–102.
A skilled artisan therefore would have been motivated to use Simonetti’s allow/deny data organization in Patrick’s policy-management system to:
Efficiently determine which permissions remain valid;
Preserve an identifiable representation of permissions that have been denied or revoked;
Facilitate review and auditing of permission changes; and
Avoid repeatedly reconstructing the effective permissions from unclassified policy records.
The combination would have involved applying Simonetti’s known permission-data organization to Patrick’s known authorization-management system, with a reasonable expectation of success because both references use processors and stored policy information to administer access permissions.
Regarding claim 2, Patrick discloses:
each policy includes a policy-type designation such as GRANT or DENY, where GRANT indicates that the specified action is permitted and DENY indicates that the action is revoked. See Patrick ¶¶73–80. Patrick’s GRANT/DENY designation constitutes flag information indicating whether the corresponding authority is valid or invalid.
Simonetti similarly teaches that a policy includes an “effect statement” specifying either Allow or Deny and that the policy is classified as an allow-policy statement or deny-policy statement based on that value. See Simonetti ¶¶78–80 and 95–96.
It would have been obvious to store the GRANT/DENY or Allow/Deny designation as a flag because a binary status field is a predictable and storage-efficient way of representing whether a permission is enabled or disabled. The particular choice of a flag rather than another equivalent status representation would have been an ordinary implementation choice yielding the predictable result of identifying the validity of each authority.
Regarding claim 6, Simonetti discloses:
classifying security-policy statements into:
An allow list containing policy statements identifying permitted access; and
A deny list containing policy statements identifying denied access.
Simonetti teaches that the allow list and deny list may be implemented as lists, trees, tables, or other data structures. See Simonetti ¶¶95–96. The allow list corresponds to the claimed validity information, and the deny list corresponds to the claimed invalidity information.
Simonetti further discloses generating and updating those data structures by adding allow-policy statements to one list, adding deny-policy statements to a different list, and discarding an allow-policy statement when it does not satisfy the applicable permission restrictions. See Simonetti ¶¶97–102.
Patrick teaches receiving administrator input to edit or delete policies and changing the stored policy information in response. See Patrick ¶¶116, 156, 160, and 164.
It would have been obvious to implement Patrick’s requested policy changes by updating Simonetti’s allow and deny lists because doing so maintains an efficient and readable representation of the current effective permissions. A permission that remains authorized would be maintained as validity information, while a permission that has been revoked would be represented as invalidity information.
Regarding claim 7, Patrick discloses:
selecting an existing policy and editing or deleting the selected policy through its policy-management interface. See Patrick ¶164. Patrick also teaches that DENY revokes a previously authorized action. See Patrick ¶75.
Simonetti discloses an allow list representing authorized permissions and a separate deny list representing denied permissions. Simonetti further teaches discarding an allow-policy statement when it fails the applicable permission requirements and maintaining deny-policy statements in a separate list. See Simonetti ¶¶95–102.
In the combined system, when the administrator’s change request instructs that a previously allowed authority to be invalidated, the corresponding permission would predictably be removed from the allow list and, where continued identification of the invalid permission is desired, represented in the deny list.
It would have been obvious to delete permission from the validity information because leaving the permission in the allow list after it had been invalidated would create inconsistent authority data and could incorrectly indicate that the permission remained effective. Removing an invalidated permission from the allow list is therefore the predictable implementation of Patrick’s revocation operation using Simonetti’s separate allow/deny data structures.
Claim(s) 3 rejected under 35 U.S.C. 103 as being unpatentable over Patrick et al., (US20050097166A1) in view of Simonetti et al., (US20220385668A1) and further in view of Kamath et al., (US20170344563A1).
Regarding claim 3, the combination of Patrick and Simonetti discloses:
changing authority information but do not necessarily require notifying an affected user of every such change.
However, Kamath discloses:
an access-control system that detects a change affecting a user’s access rights and responsively generates a notification to the user. Kamath specifically teaches that when an action removes a user’s access, a notification is generated indicating that access has been lost. See Kamath ¶16. Kamath further discloses automatically generating notifications when file access changes and sending a notification identifying the resource and the loss of access. See Kamath ¶¶31–33 and 61–66.
It would have been obvious to modify the Patrick-Simonetti system to provide Kamath’s notification when authority information changes. All three references concern management of access rights to computer-controlled resources. Kamath expressly explains that notifying the user when access is lost permits the user to learn of the change promptly and, if appropriate, timely request renewed access. See Kamath ¶16.
Claim(s) 4-5 rejected under 35 U.S.C. 103 as being unpatentable over Patrick et al., (US20050097166A1) in view of Simonetti et al., (US20220385668A1) in view of Kamath et al., (US20170344563A1) and further in view of Gavrila et al., (US20020026592A1).
Regarding claim 4, the combination of Patrick and Simonetti discloses:
discloses a group hierarchy in which a group may contain users or other groups and nested memberships form a hierarchy. See Patrick ¶166. Patrick explains that each user in a group inherits the policies applied to that group and that this rule also applies to nested groups. Parent-group policies are automatically assigned to nested groups. See Patrick ¶¶166–167.
For example, Patrick discloses an Employees parent group having Contractors, Part-Time, and Middle Management nested groups, with Senior Management nested under Middle Management. The nested groups inherit the policies assigned to their respective parent groups. See Patrick ¶167. Patrick also discloses creating, reading, updating, and deleting groups, nesting groups within groups, and updating attributes associated with those groups. See Patrick ¶168.
Patrick therefore teaches the claimed linkage between first- and second-group identification information and inheritance of authority information from a parent group by a subordinate group.
Patrick does not expressly state that every later revocation of a parent-group permission automatically causes a corresponding change in subordinate-group authority information.
However, Gavrila discloses:
nested groups and directed acyclic graphs representing role-membership and role-permission inheritance. Gavrila further teaches:
Automatic propagation of updates through role-permission hierarchies;
Automatic distribution and revocation of permissions;
Automatic revocation and recalculation when a permission is revoked from a role; and
Updating the access-control lists of all objects affected by a hierarchy update.
See Gavrila ¶¶78–79; see also claims 9–12.
It would have been obvious to incorporate Gavrila’s automatic revocation and recalculation into the nested-group system of Patrick.
Both references address hierarchical role- or group-based access control and permission inheritance. Gavrila explains that automatic propagation enables access-control policies to reflect dynamic organizational changes efficiently and without extensive administrative intervention. Automatically changing subordinate-group authority information when a parent-group permission changes would also prevent stale inherited permissions and maintain consistency throughout the group hierarchy.
The proposed combination would use Gavrila’s known automatic-update technique for its intended purpose in Patrick’s known nested-group system, with a reasonable expectation of success.
Regarding claim 5, the combination of Patrick, Simonetti, Kamath and Gavrila discloses:
automatically changing inherited permissions of subordinate roles or groups when a permission or inheritance relationship changes.
Kamath teaches responsively generating a notification when a change affects access rights. See Kamath ¶¶16, 31–33, and 61–66.
It would have been obvious to notify affected users or administrators when Gavrila’s automatic propagation causes the subordinate-group authority information to change. Such a notification would alert the affected subordinate group to its loss or modification of access, facilitate administration of the group, and allow corrective action when the inherited change was unintended.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to SYED M AHSAN whose telephone number is (571)272-5018. The examiner can normally be reached 8:30 AM - 6:00 PM.
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, William Korzuch can be reached at 571-272-7589. 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.
/SYED M AHSAN/Primary Examiner, Art Unit 2491
Prosecution Insights