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 .
Response to Amendment
This communication is in response to the amendment filed on 7/27/2026. The Examiner acknowledges amended claims 1-20. No claims have been cancelled or added. Claims 1-20 are pending and claims 1-20 are rejected. Claims 1, 8, and 15 is/are independent.
The rejection(s) of claims under 35 U.S.C. § 103 have been updated based on new grounds of rejection as indicated below.
Response to Arguments
Applicant's arguments filed 7/27/2026 have been fully considered. Applicant argues (see Remarks, page 9, 5th paragraph through page 10, 3rd paragraph) that the references cited in the previous rejection fail to disclose the newly amended claim features. This argument is persuasive. Therefore, the rejections are withdrawn. However, upon further consideration, a new ground of rejection is made in view of Park et al. U.S. Publication 20080313716 (hereinafter “Park”) in view of Jain et al. U.S. Publication 20120042395 (hereinafter “Jain”), further in view of Ignaci et al. U.S. Publication 20110154024 (hereinafter “Ignaci”). Ignaci teaches selection of a certificate authority based on a security profile of a requesting entity, and the security profile indicates a set of permissions (para 15, 24, 31, 34, and 37).
Independent claims 8 and 15 recite limitations analogous to the limitations of claim 1 and are also rejected for similar reasons. Regarding applicant’s arguments with respect to the dependent claims 2-7, 9-14, and 16-20, applicant’s amendments to the independent claims have necessitated a new ground of rejection with respect to the independent claims from which the dependent claims depend, thereby requiring new grounds of rejection for the dependent claims also. The dependent claims inherit the limitations of the independent claims from which the dependent claims depend and are rejected for the same reasons. Furthermore, the dependent claims do not recite additional limitations that are allowable, as indicated in office action below.
Accordingly, Applicant's argument is persuasive, the rejection is withdrawn, and new ground(s) of rejection are presented herein. Note that this action is made FINAL. See MPEP § 706.07(a).
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.
The factual inquiries set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
Claims 1-4, 8-11, and 15-18 is/are rejected under 35 U.S.C. 103 as being unpatentable over Park et al. U.S. Publication 20080313716 (hereinafter “Park”) in view of Jain et al. U.S. Publication 20120042395 (hereinafter “Jain”), further in view of Ignaci et al. U.S. Publication 20110154024 (hereinafter “Ignaci”).
As per claim 1, Park discloses
A system [figure 1, application role server 150; figure 6] that performs operations:
determining an access role [select from the highest permission/service corresponding to roles assigned to user, para. 20] of a node in a plurality of nodes [determining role of user operating workstation requesting resource, para. 20, 67; Zero or more workstations 133A-133Z can be owned or controlled by a user; plurality of nodes disclosed by all the user computing devices shown in figure 1] of a distributed computing system [see figure 1 or figure 6, all the computing devices in each figure make up the distributed computing system], the access role defining one or more permissions [“permissions to access one or more resources can be associated with one or more roles”, para. 17] of the node with respect to accessing system resources of the distributed computing system;
[0002] This invention relates generally to controlling access to computing resources in a distributed environment, and more specifically to providing role-based access control to computing resources in a resource sharing community encompassing several organizations.
[0005] A method for controlling access to a plurality of computing resources in a distributed computing environment can comprise the steps of: an application role server responsive to receiving a certificate request, authenticating the requester and issuing a digital certificate to the requester; an access control node responsive to receiving a resource access request, granting access to the computing resource to the requester upon ascertaining the requestor's access privileges, or forwarding the resource access request to another access control node.
[0017] Each resource can have a set of permissions associated with it. In accordance with the role-based access control (RBAC) approach, permissions to access one or more resources can be associated with one or more roles, and one or more users can be assigned to one or more roles, thereby acquiring the roles' permissions. Park [0020] In order to establish the access permitted and/or the service level to a given resource for a particular user requesting the resource, the entity controlling access to the resource (e.g., ultrapeer node 112 of FIG. 1) can select from the Permission Role Assignment Table the highest permission and/or the highest service level among the permissions and service levels corresponding to the roles to which the user is assigned.
Park [0067] The resource sharing community depicted in FIG. 6 can include a multitude of users 100A-100Z. Zero or more workstations 133A-133Z can be owned or controlled by a user. A workstation can be, e.g., a personal computer (PC), or any other computing device capable of communicating with other computing devices over a network.
identifying, based on the access role of the node, a certificate authority [application role server issues a digital certificate to the requester, para. 5; the application role server identifies itself as the certificate authority] corresponding to the access role; [B7…digital certificate includes role assignment information for said computing resource requester and the digital certificate is generated by the application role server, para. 92]
assigning, to the node, an access certificate generated by a certificate authority [application role server issues a digital certificate to the requester, para. 5; access certificate disclosed by digital certificate, para. 5 or light-weight peer certificates (LWPC), para. 21] and corresponding to the access role of the node; and [B7…said digital certificate includes role assignment information for said computing resource requester, para. 92]
controlling, based on the access certificate of the node, whether an access request initiated by the node is allowed.
[granting access to the computing resource to the requester upon ascertaining the requestor's access privileges, para. 5; sending to the user the certificate generated by the application role server to facilitate access to the resource discloses controlling, based on the access certificate of the node, whether an access request initiated by the node is allowed; otherwise, the ultrapeer node cannot successfully perform second-level authentication (para. 43) to allow user access, and so user access is effectively denied if the certificate is not sent to the user; see also figure 4, where the path to allowing user access to the resource at element 495 requires issuing the user's LWPC; not sending the LWPC to user effectively denies the user access to the resource]
[0021] Application role server (ARS) 160 can act as a central authoritative source of user identity and role assignment information. Application role server 160 can issue to users light-weight peer certificates (LWPC). An LWPC contains user identity and user role assignment information, and is electronically signed by the issuer (application role server 160). The LWPC structure is shown in FIG. 3. Thus, a user can provide his or her LWPC to any entity within the inter-organizational community as the proof of the user's identity and role assignment.
Park [0043] At step 460, ultrapeer node 112A of FIG. 1 verifies the validity of the presented LWPC and performs the second-level user authentication. In one embodiment, ultrapeer node can apply the hashing algorithm to the password supplied by the user as part of the resource access request, and compare the result with the password hash stored in the user's LWPC. In another embodiment, ultrapeer node can decrypt the user's password stored in the LWPC using the public key of the issuer of the certificate (e.g., application role server 160) and compare the result with the password supplied by the user as part of the resource access request. If the second-level user authentication has been successful, the processing continues at step 470; otherwise the method branches to step 499.
[0045] Each of the peer ultrapeer nodes, e.g., ultrapeer node 112B of FIG. 1, upon receiving a resource search request message, can look up the resource description or identifier in its Resource Description Table. If one or more resources satisfying the search request are located, ultrapeer node 112B of FIG. 1 can ascertain that the user's role included within the resource search request is allowed the access to each of the resources located, by looking up the Permission Role Assignment Table.
However, Park does not expressly disclose
A system comprising:
a processing device; and
a memory device including instructions that are executable by the processing device for causing the processing device to perform operations comprising:
selecting a certificate authority from a set of certificate authorities by verifying that the access role of the node is compatible with an access role of the certificate authority;
assigning, to the node, an access certificate generated by the certificate authority and corresponding to the access role of the node; and
[Park discloses a certificate authority assigning the access certificate but not that the certificate authority performing the assigning has been selected from a set of certificate authorities ]
Jain discloses a system with processing device, memory, instructions, and the processing device executing the instructions to perform operations
[0093] Embodiments may include various steps, which may be embodied in machine/computer-executable instructions stored on a memory configured to be executed by a processor within a general-purpose or special-purpose computing device, such as a personal computer, a laptop computer, a mobile computer, a personal digital assistant, smart phone, or the like. Alternatively, the steps may be performed by hardware components that include specific logic for performing the steps, or by a combination of hardware, software, and/or firmware.
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to have modified Park with the technique for implementing a computing system to perform operations of Jain to include
A system comprising:
a processing device; and
a memory device including instructions that are executable by the processing device for causing the processing device to perform operations comprising:
One of ordinary skill in the art would have made this modification to improve the ability of the system to apply a computing device to perform the functions described in the primary reference. The system of the primary reference can be modified to include a system with processing device, memory, instructions, and the processing device executing the instructions to perform operations.
However, the combination of Park and Jain does not expressly disclose
selecting a certificate authority from a set of certificate authorities by verifying that the access role of the node is compatible with an access role of the certificate authority;
assigning, to the node, an access certificate generated by the certificate authority and corresponding to the access role of the node; and
[Park discloses a certificate authority assigning the access certificate but not that the certificate authority has been selected from a set of certificate authorities.
under the broadest reasonable interpretation, and based on the specification, access role is interpreted as a set of permissions for the node. The specification does not explicitly define the access role and the specification (“Each node in the distributed computing system can be assigned a respective access role that grants suitable access permissions for the node to perform its functionality.”, Specification Para. 9) also appears to use access role as representing a set of permissions.
]
Ignaci discloses selecting a certificate authority [determine (218) the appropriate certificate authority, para 37] from a set of certificate authorities [plurality of certificate authorities to process the certificate service request, para. 15] by verifying that the access role [security profile, para. 37; Ignaci security profile includes information that is similar to role information such as security clearance and group information at para 31 ] of the node is compatible with an access role [there is a mapping from the security profile to the certificate authority, para 37] of the certificate authority;
assigning, to the node, an access certificate generated by the certificate authority [the Ignaci certificate authority that is selected signs the certificate, para. 15, 20; facilitate certificate authority selection and the certificate authority signing the certificate, para 34] and corresponding [certificate corresponds to the Ignaci security profile because of the security profile look up and Ignaci certificate signature process] to the access role of the node; and
Ignaci [0015] Generally speaking, pursuant to the various embodiments, a certificate authority selection unit implements a method for selecting one of a plurality of certificate authorities that service a plurality of administrative domains in a communication system. The method includes: receiving, from an end-entity via an interface, a certificate service request associated with an identifier; selecting, based on the identifier, one of the plurality of administrative domains in the communication system, wherein the plurality of administrative domain are serviced by a plurality of certificate authorities; retrieving a security profile for the end-entity; and selecting, based on the security profile for the end-entity, one of the plurality of certificate authorities to process the certificate service request.
[0020] When an end-entity requires a signed certificate or other updating of a certificate in order to operate in a public key cryptography system, a certificate service request (CSR) for the end-entity is channeled to a certificate authority selection unit 120 that performs a method in accordance with the teachings herein to select the correct certificate authority (CA) to process the service CSR.
[0024] A certificate service request includes, but is not limited to, a request for certificate enrollment, renewal, or revocation. Certificate enrollment is a process of an end-entity applying for a certificate.
Ignaci [0031] Turning back to FIG. 2, when the administrative domain is selected for the end-entity request, the certificate authority selection unit 120 retrieves an end entity security profile (ESP) in the administrative domain, block 206, and verifies the service request. The ESP includes one or more parameters or fields such as, Organization Name (O), Organizational Unit (OU), Level of Assurance (LoA), Security Clearance (SC),
[0034] enabling the registration and certificate authorities to verify the request and issue the certificate according to the policies/rules. Thus, in this embodiment, the policies of the administrative domain and the end entity security profile facilitate certificate authority selection and the certificate authority signing the certificate.
Ignaci [0037] The administrative entity vets the end-entity service request and validates and/or signs the service request prior to forwarding the certificate onto the certificate authority (mapped to the AE) for signing. The administrative entity may be a human or a server or database or other computer-based medium that receives the security profile as well as the identifier in the service request. Using the security profile, the administrative entity refers to a mapping table to determine (218) the appropriate certificate authority
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to have modified the combination of Park and Jain with the technique for selection of a certificate authority based on security profile of a requesting entity of Ignaci to include
selecting a certificate authority from a set of certificate authorities by verifying that the access role of the node is compatible with an access role of the certificate authority;
assigning, to the node, an access certificate generated by the certificate authority and corresponding to the access role of the node; and
One of ordinary skill in the art would have made this modification to improve the ability of the system to allow various certificate authorities with different capabilities and privileges to be chosen to sign certificates for a requesting entity. Certificate authorities may be associated with different degrees of trust or privileges, and it would be beneficial to allow for selecting a particular certificate authority to sign a certificate based on the permissions of the requesting party.
As per claim 2, the rejection of claim 1 is incorporated herein.
Park discloses wherein the node is a first node in the plurality of nodes, and wherein controlling whether the access request initiated by the first node is allowed comprises:
receiving, by a second node [ultrapeer node 112A of FIG. 1] of the plurality of nodes, the access request initiated by the first node using the access certificate, wherein the access request indicates [the requested operation is to access the data, para 43, 45] an operation to be performed by the first node;[ ultrapeer node can decrypt the user's password stored in the LWPC using the public key of the issuer of the certificate (e.g., application role server 160) and compare the result with the password supplied by the user as part of the resource access request; access certificate disclosed by digital certificate, para. 5 or light-weight peer certificates (LWPC), para. 21]
[0021] Application role server (ARS) 160 can act as a central authoritative source of user identity and role assignment information. Application role server 160 can issue to users light-weight peer certificates (LWPC). An LWPC contains user identity and user role assignment information, and is electronically signed by the issuer (application role server 160). The LWPC structure is shown in FIG. 3. Thus, a user can provide his or her LWPC to any entity within the inter-organizational community as the proof of the user's identity and role assignment.
Park [0043] At step 460, ultrapeer node 112A of FIG. 1 verifies the validity of the presented LWPC and performs the second-level user authentication. In one embodiment, ultrapeer node can apply the hashing algorithm to the password supplied by the user as part of the resource access request, and compare the result with the password hash stored in the user's LWPC. In another embodiment, ultrapeer node can decrypt the user's password stored in the LWPC using the public key of the issuer of the certificate (e.g., application role server 160) and compare the result with the password supplied by the user as part of the resource access request. If the second-level user authentication has been successful, the processing continues at step 470; otherwise the method branches to step 499.
[0045] Each of the peer ultrapeer nodes, e.g., ultrapeer node 112B of FIG. 1, upon receiving a resource search request message, can look up the resource description or identifier in its Resource Description Table. If one or more resources satisfying the search request are located, ultrapeer node 112B of FIG. 1 can ascertain that the user's role included within the resource search request is allowed the access to each of the resources located, by looking up the Permission Role Assignment Table. Finally, ultrapeer node 112B of FIG. 1 can build a resource search response message, including the descriptions and/or identifiers of all the resources which satisfy the search request parameters, and which the user is allowed to access.
determining, by the second node, whether the access request is valid [ultrapeer node can decrypt the user's password stored in the LWPC using the public key of the issuer of the certificate (e.g., application role server 160) and compare the result with the password supplied by the user as part of the resource access request, para. 43 ]by comparing [ ascertain that the user's role included within the resource search request is allowed the access to each of the resources located, para. 45] the one or more permissions [allowed the access, para 45] of the access role to access permissions requested [the request to access the resource of para. 45] to perform the operation; and
[this comparing is interpreted as determining that the requesting party has the permissions that they requested; here, the Park system determines that the user’s role does include the access permissions of the access request at para 45]
]
in response to determining that the access request is valid, allowing, by the second node, the access request such that the first node is permitted to perform the operation indicated in the access request.[ If the second-level user authentication has been successful, ultrapeer node 112A of FIG. 1 performs the search requested by the user, para. 43-44; the user's role included within the resource search request is allowed the access to each of the resources located, para. 45 ]
[0044] At step 470, ultrapeer node 112A of FIG. 1 performs the search of the resource using the resource description or identifier supplied by the user as part of the resource access request. Ultrapeer node 112A of FIG. 1 can perform the search by ascertaining whether a resource satisfying the resource access request exists among the resources controlled by ultrapeer node 112A itself, and/or by sending resource search request messages to peer ultrapeer nodes. A resource search request messages can include the resource description or identifier, and the user role information.
Park [0045] Each of the peer ultrapeer nodes, e.g., ultrapeer node 112B of FIG. 1, upon receiving a resource search request message, can look up the resource description or identifier in its Resource Description Table. If one or more resources satisfying the search request are located, ultrapeer node 112B of FIG. 1 can ascertain that the user's role included within the resource search request is allowed the access to each of the resources located, by looking up the Permission Role Assignment Table
As per claim 3, the rejection of claim 2 is incorporated herein.
Park discloses wherein determining that the access request is valid further comprises:
identifying, by the second node using the access certificate, the certificate authority that generated the access certificate;
[ultrapeer node can decrypt the user's password stored in the LWPC using the public key of the issuer of the certificate (e.g., application role server 160) and compare the result with the password supplied by the user as part of the resource access request, para. 43 ]
determining, by the second node, the one or more permissions of the first node based on the certificate authority; and [at para. 44 ultrapeer node determines the user has access to the resources located based on decrypting the user’s password in the LWPC at para. 43 and looking up the permission table at para. 44; the entity issuing an LWPC (e.g., application role server 160 of FIG. 1) at para. 33]
[0044] At step 470, ultrapeer node 112A of FIG. 1 performs the search of the resource using the resource description or identifier supplied by the user as part of the resource access request.
[0045] Each of the peer ultrapeer nodes, e.g., ultrapeer node 112B of FIG. 1, upon receiving a resource search request message, can look up the resource description or identifier in its Resource Description Table. If one or more resources satisfying the search request are located, ultrapeer node 112B of FIG. 1 can ascertain that the user's role included within the resource search request is allowed the access to each of the resources located, by looking up the Permission Role Assignment Table
verifying, by the second node, that the operation indicated in the access request is consistent with the one or more permissions of the first node.[ first node disclosed by the user’s computing device; ascertain that the user's role included within the resource search request is allowed the access to each of the resources located, para. 45]
As per claim 4, the rejection of claim 2 is incorporated herein.
Park discloses wherein the operations further comprise, in response to determining that the access request is invalid:
denying, [access not authorized, resource not found, para. 50, 51] by the second node, [ultrapeer node 112B of FIG. 1 ]the access request to prevent the first node from performing the operation.
[0048] At step 492, ultrapeer node 112B of FIG. 1 ascertains whether the user is allowed access to the resource, e.g., by selecting from the Permission Role Assignment Table the highest permission and/or the highest service level among the permissions and service level corresponding to the roles to which the user is assigned. If the resource access is authorized, the processing continues at step 495; otherwise, the method branches to step 499.
[0050] At step 498, the "Access not authorized" message is returned to the user, and the method terminates.
[0051] At step 499, the "Resource not found" message is returned to the user, and the method terminates.
As per claim 8, the claim(s) is/are directed to a method with limitations which correspond to limitations of claim 1, and is/are rejected for the reasons detailed with respect to claim 1. Claim 8 also recites a method comprising
Park discloses a method comprising
[0005] A method for controlling access to a plurality of computing resources in a distributed computing environment can comprise the steps of:
As per claim 9, the claim(s) is/are directed to a method with limitations which correspond to limitations of claim 2, and is/are rejected for the reasons detailed with respect to claim 2.
As per claim 10, the claim(s) is/are directed to a method with limitations which correspond to limitations of claim 3, and is/are rejected for the reasons detailed with respect to claim 3.
As per claim 11, the claim(s) is/are directed to a method with limitations which correspond to limitations of claim 4, and is/are rejected for the reasons detailed with respect to claim 4.
As per claim 15, the claim(s) is/are directed to a computer readable medium with limitations which correspond to limitations of claim 1, and is/are rejected for the reasons detailed with respect to claim 1. Claim 15 also recites
A non-transitory computer-readable medium comprising program code executable by a processing device for causing the processing device to perform operations comprising:
However, Park does not expressly disclose
A non-transitory computer-readable medium comprising program code executable by a processing device for causing the processing device to perform operations comprising:
Jain discloses a system with processing device, memory, instructions, and the processing device executing the instructions to perform operations
[0093] Embodiments may include various steps, which may be embodied in machine/computer-executable instructions stored on a memory configured to be executed by a processor within a general-purpose or special-purpose computing device, such as a personal computer, a laptop computer, a mobile computer, a personal digital assistant, smart phone, or the like. Alternatively, the steps may be performed by hardware components that include specific logic for performing the steps, or by a combination of hardware, software, and/or firmware.
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to have modified Park with the technique for implementing a computing system to perform operations of Jain to include A system comprising:
A non-transitory computer-readable medium comprising program code executable by a processing device for causing the processing device to perform operations comprising:
One of ordinary skill in the art would have made this modification to improve the ability of the system to apply a computing device to perform the functions described in the primary reference. The system of the primary reference can be modified to include a system with processing device, memory, instructions, and the processing device executing the instructions to perform operations.
As per claim 16, the claim(s) is/are directed to a computer readable medium with limitations which correspond to limitations of claim 2, and is/are rejected for the reasons detailed with respect to claim 2.
As per claim 17, the claim(s) is/are directed to a computer readable medium with limitations which correspond to limitations of claim 3, and is/are rejected for the reasons detailed with respect to claim 3.
As per claim 18, the claim(s) is/are directed to a computer readable medium with limitations which correspond to limitations of claim 4, and is/are rejected for the reasons detailed with respect to claim 4.
Claims 5-6, 12-13, and 19-20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Park in view of Jain, in view of Ignaci, further in view of Graff et al. U.S. Publication 20050144144 (hereinafter “Graff”).
As per claim 5, the rejection of claim 1 is incorporated herein.
However, the combination of Park, Jain, and Ignaci does not expressly disclose
wherein the node is assigned a set of access certificates, and wherein each access certificate of the set of access certificates assigned to the node is generated by a respective certificate authority that grants a respective set of permissions.
Graff discloses multiple certificate authorities can issue permission certificates to a requesting terminal
[0007] In light of the foregoing background, embodiments of the present invention provide an improved system and method for authenticating a terminal based upon at least one characteristic of the terminal located at a position within an organization. In contrast to conventional techniques for authenticating entities, embodiments of the present invention provide a primary certification authority (CA) capable of issuing identity certificates, secondary CA's capable of issuing role certificates based upon a position of the requesting terminal within an organization, and tertiary CA's capable of issuing permission certificates based upon characteristic(s) of the requesting terminal located at a position within the organization. The primary CA can be capable of issuing identity certificates to one or more organizations. One or more secondary CA's can be capable of issuing role certificates to one or more groups of terminals of one or more organizations. In turn, one or more tertiary CA's can advantageously be capable of issuing permission certificates to one or more sub-groups of terminals of one or more organizations. By distributing issuance of certificates between the primary, secondary and tertiary CA's, each respective CA can provide better control over the certificates issued by the respective CA.
Graff [0066] If the server 14 verifies and validates the identity certificate the terminal 16, the server can continue by verifying the position of the terminal within the organization based upon the role certificate, to thereby determine if and to what extent the terminal is authorized to access the resources of the server
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to have modified the combination of Park, Jain, and Ignaci with the technique for multiple certificate authorities each issues a respective permission certificate to a requesting terminal of Graff to include wherein the node is assigned a set of access certificates, and wherein each access certificate of the set of access certificates assigned to the node is generated by a respective certificate authority that grants a respective set of permissions.
One of ordinary skill in the art would have made this modification to improve the ability of the system to allow for different certificate authorities to grant different permissions to a device. The system of the primary reference can be modified to have multiple certificate authorities each generating an access certificate corresponding to respective permissions for a device.
As per claim 6, the rejection of claim 5 is incorporated herein.
However, the combination of Park, Jain, and Ignaci does not expressly disclose
wherein the operations further comprise, prior to initiating the access request:
determining a request type of the access request;
selecting, by the node from the set of access certificates, a particular access certificate compatible with the request type; and
generating, by the node, the access request using the selected access certificate.
Graff discloses
prior to initiating the access request:
determining a request type of the access request; [the type of the request is request with certificates as described at para. 64]
selecting, by the node from the set of access certificates, a particular access certificate compatible with the request type; and [the request includes permission certificate and a bound role certificate, along with an identity certificate bound to the role certificate, as shown in block 96, para. 64; particular access certificate disclosed by any one of the certificates attached to the request]
generating, by the node, the access request using the selected access certificate.
[sending a request to the server, para. 64]
[Graff discloses terminal sending request to server with at least one certificate ]
[0064] At one or more points in time after the terminal 16 stores the identity certificate, role certificate(s) and permission certificate(s), the terminal can initiate communication with one or more servers 14 to thereby request access to resources available from, or controlled by, the server(s). As shown in FIG. 7, a terminal can request access the resources of the server by first sending a request to the server, where the request includes permission certificate and a bound role certificate, along with an identity certificate bound to the role certificate, as shown in block 96. In this regard, the server can be capable of permitting the terminal to access resources of the server in accordance with the characteristic(s) of the terminal identified in the permission certificate, the terminal being at a position identified in the role certificate. Before permitting such access, however, the server can validate the permission certificate, role certificate and identity certificate to thereby authenticate and authorize the terminal for access to the resources.
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to have modified the combination of Park, Jain, and Ignaci with the technique for a terminal sending request to server with certificates of Graff to include
wherein the operations further comprise, prior to initiating the access request:
determining a request type of the access request;
selecting, by the node from the set of access certificates, a particular access certificate compatible with the request type; and
generating, by the node, the access request using the selected access certificate.
One of ordinary skill in the art would have made this modification to improve the ability of the system to allow for the user machine to send one or more certificates to a server as needed to get access according to the permissions of the different certificates. The system of the primary reference can be modified so that the user’s machine can attach certificates to a request and send such requests with attached certificates to a server to request access.
As per claim 12, the claim(s) is/are directed to a method with limitations which correspond to limitations of claim 5, and is/are rejected for the reasons detailed with respect to claim 5.
As per claim 13, the claim(s) is/are directed to a method with limitations which correspond to limitations of claim 6, and is/are rejected for the reasons detailed with respect to claim 6.
As per claim 19, the claim(s) is/are directed to a computer readable medium with limitations which correspond to limitations of claim 5, and is/are rejected for the reasons detailed with respect to claim 5.
As per claim 20, the claim(s) is/are directed to a computer readable medium with limitations which correspond to limitations of claim 6, and is/are rejected for the reasons detailed with respect to claim 6.
Claims 7 and 14 is/are rejected under 35 U.S.C. 103 as being unpatentable over Park in view of Jain, in view of Ignaci, further in view of Panchamia et al. U.S. Publication 20220394028 (hereinafter “Panchamia”).
As per claim 7, the rejection of claim 1 is incorporated herein.
However, the combination of Park, Jain, and Ignaci does not expressly disclose
wherein the operations further comprise:
determining that the node has been compromised; and
in response to determining that the node has been compromised, revoking the access certificate of the compromised node to remove the one or more permissions associated with the compromised node.
Panchamia discloses determining that the node has been compromised; and
in response to determining that the node has been compromised, revoking [invalidate role certificate if device compromised, para. 160] the access certificate of the compromised node to remove the one or more permissions [role certificates allows for creating different levels of permissions, para. 116; when such certificate is invalidated according to para. 160 then the permissions would be removed] associated with the compromised node.
[0116] The use of role certificates in an to system allows for an operator of the system to create different levels of permission and different groups with specific permissions. The operator may specify specific communities of interest which define these permissions. For example, an operator for a group of elevators may for each elevator configure a control for an actuator and a control for a user interface. The operator can configure the role certificates for each device to ensure that the control for one elevator only communicates with the actuator for the same elevator and not an actuator for a different elevator.
Panchamia [0160] A device operator invalidates the second IoT device's role certificate at the operation 1708. In some examples, the device operator invalidates the second IoT device's role certificate after an indication that the device is compromised. For example, a monitoring service on the active communication channel may notice that malicious traffic is being sent from the second IoT device. In another example, the device operator may be aware of a security issue for a device from a specific manufacturer and can invalidate the role certificates for each device made by the specific manufacturer. Other services can be used to give the device operator an indication that a device may be a risk to the network. In some examples, in order to revoke a role certificate for a device the device operator must be a trust anchor for the device.
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to have modified the combination of Park, Jain, and Ignaci with the technique for invalidating a role certificate when a device is compromised of Panchamia to include
wherein the operations further comprise:
determining that the node has been compromised; and
in response to determining that the node has been compromised, revoking the access certificate of the compromised node to remove the one or more permissions associated with the compromised node.
One of ordinary skill in the art would have made this modification to improve the ability of the system to take preventive measures to mitigate potential damage to computing systems and data when a device is compromised, by invalidating the certificate for the device and thereby invalidating the permissions associated with the certificate.
As per claim 14, the claim(s) is/are directed to a method with limitations which correspond to limitations of claim 7 and is/are rejected for the reasons detailed with respect to claim 7.
Conclusion
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 HOWARD H LOUIE whose telephone number is (571)272-0036. The examiner can normally be reached on Monday-Friday 9 AM-5 PM EST.
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, Jung W. Kim can be reached on 571-272-3804. 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.
/HOWARD H. LOUIE/Examiner, Art Unit 2494
/THEODORE C PARSONS/Primary Examiner, Art Unit 2494
Prosecution Insights