DETAILED ACTION
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.
This Office Action is in response to the communication filed on 03/25/2026.
Claims 1 and 20 have been amended.
Claims 1-20 are pending for consideration.
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 .
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 03/25/2026 has been entered.
Response to Arguments
Applicant's arguments filed 03/25/2026 have been fully considered but they are not persuasive. Regarding claims 1, 14, and 20, Applicant argues that Mital fails to teach the attachment of policy tokens to logs. Instead, Mital teaches a context that does not equate to a token representative of a policy. Furthermore, Mital's context is not attached to a log.
Examiner disagrees. Mital teaches the anonymization of data via tokenizing/encrypting data, wherein the tokenizing/encryption is dependent on the policy for the data (Mital: see Col 7 lines 2-6, "In such embodiments, the anonymizing further includes identifying the data to be anonymized. The anonymizing may include tokenizing and/or encrypting the data. The tokenizing and/or encrypting may be selected based upon a policy for the data"). Mital also teaches attaching the policy tokens to the logs (Mital: see Col 19 lines 35-38, "Sidecar 110 receives an identification of information of interest in the data source(s) 102 and/or 104, at 902. Also at 902, policies related to the sensitive information are also received"). Mital does not explicitly "attach" the policy to the data. Instead, Mital teaches the sending of the data with the policies related to the data.
Applicant argues that Mital fails to teach providing policy tokens together with the logs to a collector as the flow of Mital runs in the opposite direction. Examiner disagrees. Mital also teaches receiving both the data to be protected/accessed and the policies that should be applied to the data being accessed by a sidecar (Mital: see Col 19 lines 35-58, "Sidecar 110 receives an identification of information of interest in the data source(s) 102 and/or 104, at 902. Also at 902, policies related to the sensitive information are also received. Reception of this information at 902 may be decoupled from receiving queries and analyzing queries for the remainder of method 900. For example, owner(s) of data source(s) 102 and/or 104 may indicated to sidecar 110 which tables, columns/rows in the tables, and/or entries in the tables include information that is of interest or sensitive. For example, tables including customer names, social security numbers (SSNs) and/or credit card numbers (CCNs) may be identified at 902. Columns within the tables indicating the SSN, CCN and customer name, and/or individual entries such as a particular customer's name, may also be identified at 902. This identification provides to sidecar 110 information which is desired to be logged and/or otherwise managed. Further, policies related to this information are provided at 902. Whether any logging is to be performed or limited is provided to sidecar at 902. For example, any user access of customer tables may be desired to be logged. The policies indicate that queries including such accesses are to be logged. Whether data such as SSNs generated by a query of the customer table should be redacted for the log may also be indicated in the policies"). While Mital does not explicitly use the collector to receive the policy and data, and enforce the policy on the data, changing the enforcer/receiver from a sidecar to a collector in the present application is a design choice.
Regarding claim 7, Applicant argues that Payment does not teach identifying an attribute of a first log, and that Payment only teaches a determination of whether to grant a request for access to a resource. Examiner disagrees. The Specification of the instant application [paragraph 0044] teaches the identification of one more attributes of a log and searching/determining policy that matches and/or coincides with the identified attributes of the one or more logs. Payment teaches the identification of an access-control policy based on attributes of a received request [paragraph 0030, "An identity may be associated with the one or more attribute-based permissions (also referred to as attribute-based access control policies). For example, a role may be assigned to the identity and that the role corresponds to one or more attribute-based access control policies"].
Applicant argues that Payment does not teach searching policy tokens as the graph traversal of Payment does not involve a set of tokens attached to or used with logs. Examiner disagrees. While Payment does not explicitly traverse policy tokens, utilizing Payment's traversal of a graph representing access control policies with the policy tokens of Murdoch and Shimoe is an obvious combination that allows the use of an attribute to identify applicable policies or permissions. This query/search/mapping methodology is well known in Attribute Based Access Control Systems.
Applicant argues that Payment does not teach determining that a first policy token represents a policy matching an attribute of a first log; instead, Payment teaches determining whether a policy matches a request based on resource metadata and a predicate. Examiner disagrees. An attribute of a log is comparable to the metadata of a request. The Specification of the instant application [paragraph 0050] describes an attribute as "specific entities, specific customers, specific tenants, specific users, specific roles, groups of users and/or tenants, users or groups authorized by an authority, users or groups with specific security levels, combinations or variations of one or more of the same, and/or any other suitable attributes". Payment teaches the determination of access control policies can be based on, amongst other things, a role of an identity (Payment: see paragraph 0039, "In various embodiments, a role may be created for an identity to include one or more attribute-based access control policies (also referred to as attribute-based permissions). In various embodiments, a user may be a person, a group of people, or an application").
In response to applicant's argument that the examiner has combined an excessive number of references, reliance on a large number of references in a rejection does not, without more, weigh against the obviousness of the claimed invention. See In re Gorman, 933 F.2d 982, 18 USPQ2d 1885 (Fed. Cir. 1991).
Specification
Applicant is reminded of the proper content of an abstract of the disclosure.
A patent abstract is a concise statement of the technical disclosure of the patent and should include that which is new in the art to which the invention pertains. The abstract should not refer to purported merits or speculative applications of the invention and should not compare the invention with the prior art.
If the patent is of a basic nature, the entire technical disclosure may be new in the art, and the abstract should be directed to the entire disclosure. If the patent is in the nature of an improvement in an old apparatus, process, product, or composition, the abstract should include the technical disclosure of the improvement. The abstract should also mention by way of example any preferred modifications or alternatives.
Where applicable, the abstract should include the following: (1) if a machine or apparatus, its organization and operation; (2) if an article, its method of making; (3) if a chemical compound, its identity and use; (4) if a mixture, its ingredients; (5) if a process, the steps.
Extensive mechanical and design details of an apparatus should not be included in the abstract. The abstract should be in narrative form and generally limited to a single paragraph within the range of 50 to 150 words in length.
See MPEP § 608.01(b) for guidelines for the preparation of patent abstracts.
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.
Claims 1-4, 6, 8, 10-12, 14-17, and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Murdoch et al. (US 2020/0401734)(hereinafter Murdoch) in view of Shimoe (US2011/0231900)(hereinafter Shimoe), and in further view of Mital et al. (U.S. 11, 477, 197) (hereinafter Mital).
Regarding claims 1, 14, and 20 Murdoch teaches a system comprising at least one network device (Murdoch: see Fig. 3 item 201); at least one collector (Murdoch: see Fig. 3 item 301) ; and at least one service (Murdoch: see Fig. 3 item 320) configured to: provide, to the network device and the collector, a key identifier that enables the network device to generate an encryption key for encrypting one or more logs and enables the collector to decrypt the logs (Murdoch: see Page 9 paragraph 0106 lines 2-13, “... a seed 501, a personal storage identifier 502, and a key identifier 503 are used as three inputs 505, 506, and 507 into a function 504 to generate an output 508. The output 508 is then used as an encryption/decryption key 509 for encrypting a data object 506. The data object 506 is a data object that is stored or is to be stored in a personal storage (e.g., identity hub 411) that is associated with a DID. After the data object 506 is encrypted, the data object 506 is converted to the encrypted data object 510. The encrypted data object 510 is often called ciphertext, which can only be viewed in its original form if it is decrypted with the correct decryption key 509”).
However, Murdoch fails to teach provide, to the network device, one or more policy tokens representative of one or more policies that control access to the logs; attach the policy tokens policy tokens to the logs; and provide, to the collector, the policy tokens together with the logs to enable the collector to enforce the policies represented by the policy tokens attached to the logs.
Nevertheless, Shimoe-which is in the same field of endeavor-teaches provide, to the network device, one or more policy tokens representative of one or more policies that control access to the logs (Shimoe: see Page 2 paragraph 0028 lines 3-6, “In FIG. 1, a device that manages (generates, verifies, distributes, etc.) security policies (access control principles) is indicated as a policy administration point (PAP)...”); and provide, to the collector, the policy tokens to enable the collector to enforce the policies represented by the policy tokens (Shimoe: see Page 2 paragraph 0028 lines 6-10, “...a device that makes a determination of whether access is permitted on the basis of an access control policy (access control information) is indicated as a policy decision point (PDP), and a device that actually controls whether to allow access is indicated as a policy enforcement point (PEP)”).
Murdoch and Shimoe are analogous art because they are from the same field of endeavor, administering access control systems. Before the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art to utilize Murdoch’s encryption and decryption key generation with Shimoe’s access policy token to control access to device logs. The suggestion/motivation for doing so would be to prevent tenants, users, or devices in a shared environment from accessing other tenant, user, or device data.
However, Murdoch and Shimoe fail to teach attach the policy tokens policy tokens to the logs; and providing the policy tokens together with the logs.
Nevertheless, Mital-which is in the same field of endeavor- teaches attach the policy tokens policy tokens to the logs (Mital: see Col 6 lines 29-31, "The method and system include receiving, at the sidecar, a communication and a context associated with the communication from a client"; Col 19 lines 35-38, "Sidecar 110 receives an identification of information of interest in the data source(s) 102 and/or 104, at 902. Also at 902, policies related to the sensitive information are also received"); and providing the policy tokens together with the logs (Mital: see Col 19 lines 35-38, "Sidecar 110 receives an identification of information of interest in the data source(s) 102 and/or 104, at 902. Also at 902, policies related to the sensitive information are also received").
Murdoch, Shimoe, and Mital are analogous art because they are from the same field of endeavor, network access control protocols. Before the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art to combine Mital’s method for transmitting policy information along with protected data with Murdoch and Shimoe’s key generation/transmission protocol. The suggestion/motivation for doing so would be to support scalable systems that utilize separate modules/components to enforce or determine policies.
Regarding claims 2 and 15, Murdoch, Shimoe, and Mital teach generate the key identifier for distribution to the network device and the collector (Murdoch: see Page 10 paragraph 0109 lines 1-5, “The key identifier 503 may be an identifier generated by the system or entered by the DID owner for the particular data object, such that a different key may be generated for encrypting/decrypting a different data object stored in the same identity hub 411”); and generate the policies for distribution to the network device and the collector (Shimoe: see Page 3 paragraph 0048 lines 1-3, “The policy generating unit 612 obtains security policies from the storage unit 611 to generate an access control policy (operation S110 in FIG. 4)”). Motivation to combine Murdoch, Shimoe, and Mital, in the instant claim, is the same as that in claims 1, 14, and 20.
Regarding claims 3 and 16, Murdoch, Shimoe, and Mital teach obtain input from an administrator; and generate the policies based at least in part on the input (Shimoe: see Page 2 paragraph 0040 lines 1-5, “The system management terminal 70 receives security policies input by security administrators (e.g., chief security officers (CSOs), department heads, and data owners). The system management terminal 70 outputs the received security policies to the policy distributing apparatus 60”). Motivation to combine Murdoch, Shimoe, and Mital, in the instant claim, is the same as that in claims 1, 14, and 20.
Regarding claims 4 and 17, Murdoch, Shimoe, and Mital teach at least one additional network device (Fig. 3 item 301a; Page 6 paragraph 0070 lines 2-6, “It will be noted that in operation, the DID lifecycle management module 320 may reside on and be executed by one or more of user device 301, web browser 302, and the operating system 303 as illustrated by the lines 301a, 302a, and 303a”); provide, to the additional network device and the collector, an additional key identifier that enables the additional network device to generate an additional encryption key for encrypting one or more additional logs and enables the collector to decrypt the logs (Murdoch: see Page 9 paragraph 0106 lines 2-13, “... a seed 501, a personal storage identifier 502, and a key identifier 503 are used as three inputs 505, 506, and 507 into a function 504 to generate an output 508. The output 508 is then used as an encryption/decryption key 509 for encrypting a data object 506. The data object 506 is a data object that is stored or is to be stored in a personal storage (e.g., identity hub 411) that is associated with a DID. After the data object 506 is encrypted, the data object 506 is converted to the encrypted data object 510. The encrypted data object 510 is often called ciphertext, which can only be viewed in its original form if it is decrypted with the correct decryption key 509”); provide, to the additional network device, one or more additional policy tokens representative of one or more additional policies that control access to the additional logs (Shimoe: see Page 2 paragraph 0028 lines 3-6, “In FIG. 1, a device that manages (generates, verifies, distributes, etc.) security policies (access control principles) is indicated as a policy administration point (PAP)...”); and provide, to the collector, the additional policy tokens to enable the collector to enforce the additional policies applied by the additional network device to the additional logs (Shimoe: see Page 2 paragraph 0028 lines 6-10, “...a device that makes a determination of whether access is permitted on the basis of an access control policy (access control information) is indicated as a policy decision point (PDP), and a device that actually controls whether to allow access is indicated as a policy enforcement point (PEP)”). Motivation to combine Murdoch, Shimoe, and Mital, in the instant claim, is the same as that in claims 1, 14, and 20.
Regarding claim 6, Murdoch, Shimoe, and Mital teach attach a first policy token included in the policy tokens to a first log included in the logs (Mital: see Col 19 lines 35-38, "Sidecar 110 receives an identification of information of interest in the data source(s) 102 and/or 104, at 902. Also at 902, policies related to the sensitive information are also received"; Shimoe: see Page 5 paragraph 0079 lines 8-16, “The destination determining unit 613 extracts information about devices that match the determined types of destination devices from the destination-information management table (operation S130 in FIG. 4) and creates a distribution-destination management table that associates each access control policy with one or more destination devices to which the access control policy is to be distributed (operation S140 in FIG. 4)”); and provide, to the collector, the first policy token together with the first log (Shimoe: see Page 6 paragraph 0088, “Destination information No. 1 to No. n includes information about destinations to which an access control policy identified by an access-control-policy identifier is to be distributed. Destination information includes information for identifying each destination (e.g., a destination host name or IP address, and a port number) and information about how to distribute the access control policy (e.g., Spml, ftp, telnet, or ssh). The destination information may further include attribute information about the destination device”). Motivation to Murdoch, Shimoe, and Mital, in the instant claim, is the same as that in claims 1, 14, and 20.
Regarding claim 8, Murdoch, Shimoe, and Mital teach attach a second policy token included in the policy tokens to a second log included in the logs (Mital: see Col 19 lines 35-38, "Sidecar 110 receives an identification of information of interest in the data source(s) 102 and/or 104, at 902. Also at 902, policies related to the sensitive information are also received"; Shimoe: see Page 5 paragraph 0079 lines 8-16, “The destination determining unit 613 extracts information about devices that match the determined types of destination devices from the destination-information management table (operation S130 in FIG. 4) and creates a distribution-destination management table that associates each access control policy with one or more destination devices to which the access control policy is to be distributed (operation S140 in FIG. 4)”); and provide, to the collector, the second policy token together with the second log (Shimoe: see Page 6 paragraph 0088, “Destination information No. 1 to No. n includes information about destinations to which an access control policy identified by an access-control-policy identifier is to be distributed. Destination information includes information for identifying each destination (e.g., a destination host name or IP address, and a port number) and information about how to distribute the access control policy (e.g., Spml, ftp, telnet, or ssh). The destination information may further include attribute information about the destination device”). Motivation to combine Murdoch, Shimoe, and Mital, in the instant claim, is the same as that in claims 1, 14, and 20.
Regarding claim 10, Murdoch, Shimoe, and Mital teach generate the encryption key based at least in part on the key identifier; and encrypt the logs with the encryption key (Murdoch: see Page 9 paragraph 0106 lines 2-7, “As illustrated in FIG. 5, a seed 501, a personal storage identifier 502, and a key identifier 503 are used as three inputs 505, 506, and 507 into a function 504 to generate an output 508. The output 508 is then used as an encryption/decryption key 509 for encrypting a data object 506”). Motivation to combine Murdoch, Shimoe, and Mital, in the instant claim, is the same as that in claims 1, 14, and 20.
Regarding claim 11, Murdoch, Shimoe, and Mital teach receive a request from a user to access a log included in the logs; determine that the user is authorized to access the log; and satisfy the request by decrypting the log with the key identifier and providing the user with access to the log (Shimoe: see Page 2 paragraph 0031 lines 1-2, “The proxy server 20 receives the access request and the credentials transmitted from the client terminal 10”; Page 2 paragraph 0031 lines 6-9, “If there is the access control policy, the proxy server 20 determines, on the basis of the access control policy, whether the user of the client terminal 10 is permitted to access the target object 200”). Motivation to Murdoch, Shimoe, and Mital, in the instant claim, is the same as that in claims 1, 14, and 20.
Regarding claim 12, Murdoch, Shimoe, and Mital teach receive a request from a user to access a log included in the logs; determine that the user is not authorized to access the log; and refuse to satisfy the request due at least in part to the user not being authorized to access the log (Shimoe: see Page 2 paragraph 0031 lines 1-2, “The proxy server 20 receives the access request and the credentials transmitted from the client terminal 10”; Page 2 paragraph 0032 lines 1-3, “If the user of the client terminal 10 does not meet conditions defined by the access control policy, the proxy server 20 denies the user access to the target object 200”). Motivation to combine Murdoch, Shimoe, and Mital, in the instant claim, is the same as that in claims 1, 14, and 20.
Claims 5, 13, and 18 are rejected under 35 U.S.C. 103 as being unpatentable over Murdoch, Shimoe, and Mital, as applied to claims 1-4, 6, 8, 10-12, 14-17, and 20 above, and further in view of Mallapura et al. (US 12,375,266)(hereinafter Mallapura).
Regarding claim 5, Murdoch, Shimoe, and Mital teach the invention detailed above.
However, Murdoch, Shimoe, and Mital fail to teach sign the key identifier with a private key; and the network device is further configured to authenticate the service by validating the signature of the key identifier with a public key corresponding to the private key.
Nevertheless, Mallapura-which is in the same field of endeavor- teaches sign the key identifier with a private key; and the network device is further configured to authenticate the service by validating the signature of the key identifier with a public key corresponding to the private key (Mallapura: see Col 7 lines 1-5, “In configurations, the first node may sign, using a private key of the first node, the associated identifier with the signature. The method may further comprise validating, by the second node using a public key of the first node, the signature”).
Murdoch, Shimoe, Mital, and Mallapura are analogous art because they are from the same field of endeavor, generation of cryptographic keys. Before the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art to utilize Murdoch, Shimoe, and Mital’s inventions with Mallapura digital signature for authentication/verification. The suggestion/motivation for doing so would be to enhance non-repudiation and ensure a scalable and reliable authentication system.
Regarding claim 13, Murdoch, Shimoe, Mital, and Mallapura teach the key identifier comprises a post-quantum pre-shared key identifier (Mallapura: see Col 3 lines 15-21, “The first node may use the session key service engine to generate a PQPSK pair (including an identifier (ID) and a key) and share the PQPSK ID with the second node via an echo request message. The second node may fetch the PQPSK ID from the message and then generate the corresponding PQPSK key using the local session key service engine based on the PQPSK ID”); and the encryption key comprises a post-quantum pre-shared key (Mallapura: see Col 3 lines 24-27, “However, when the second node is successful, both the first node and the second node will have a common PQPSK key (common encryption key) which may be used to encrypt traffic between the two nodes”). Motivation to combine Murdoch, Shimoe, Mital, and Mallapura, in the instant claim, is the same as that in claim 5.
Regarding claim 18, Murdoch, Shimoe, Mital, and Mallapura teach sign the key identifier with a private key to enable the network device to validate the signature of the key identifier with a public key corresponding to the private key (Mallapura: see Col 7 lines 1-5, “In configurations, the first node may sign, using a private key of the first node, the associated identifier with the signature. The method may further comprise validating, by the second node using a public key of the first node, the signature”). Motivation to combine Murdoch, Shimoe, Mital and Mallapura, in the instant claim, is the same as that in claim 5.
Claims 9 and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Murdoch, Shimoe, and Mital, as applied to claims 1-4, 6, 8, 10-12, 14-17, and 20 above, and further in view of Antar et al. (US 11,698,958)(hereinafter Antar).
Regarding claims 9 and 19, Murdoch, Shimoe, and Mital teach the invention detailed above.
However, Murdoch, Shimoe, and Mital fail to teach provide the key identifier and the policy tokens to the collector via a distributed ledger by: adding, to the distributed ledger, a record that associates a device identifier for the network device, the key identifier, and the policy tokens; and enabling the collector to obtain the key identifier and the policy tokens from the record via the distributed ledger.
Nevertheless, Antar-which is in the same field of endeavor-teaches provide the key identifier and the policy tokens to the collector via a distributed ledger by: adding, to the distributed ledger, a record that associates a device identifier for the network device (Antar: see Col 7 lines 39-43, “The distributed database 300 may comprise a plurality of blocks 310, 320, 330, 340. Each block 310, 320, 330, 340 may comprise a distributed database record. The distributed database record may comprise data associated with a device, such as data identifying the device”), the key identifier (Antar: see Col 7 lines 41-49, “The distributed database record may comprise data associated with a device, such as data identifying the device. Each block 310, 320, 330, 340 may comprise a hash of a key (H.sub.PubKey310, H.sub.PubKey320, H.sub.PubKey330, H.sub.PubKey340) of the device. The key may comprise a public key of the device. The public key may be unique to the device. The public key may be paired with a private key of the device. Each block 310, 320, 330, 340 may comprise an address of the device (A.sub.310, A.sub.320, A.sub.330, A.sub.340”), and the policy tokens (Antar: see Col 13 lines 62-65, “A record 714, may be stored and/or created on the distributed ledger 710, wherein the record 714 may comprise information indicating platform permissions and/or rights associated with the computing device 720”); and enabling the collector to obtain the key identifier and the policy tokens from the record via the distributed ledger (Antar: see Col 27 lines 28-32, “Based on the unique identifier, the computing device may determine a first distributed ledger associated with the user. The computing device may determine a record stored and/or created on the distributed ledger indicating a second user associated with the service account”).
Murdoch, Shimoe, Mital, and Antar are analogous art because they are from the same field of endeavor, securing network protocols through the use of cryptographic arrangements. Before the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art to utilize Murdoch and Shimoe’s inventions with Antar’s distributed ledger to provide the key identifier and policy tokens to the collector. The suggestion/motivation for doing so would be to make sharing information between tenants more reliable and secure by only sharing information with authorized sources.
Claim 7 is rejected under 35 U.S.C. 103 as being unpatentable over Murdoch, Shimoe, and Mital, as applied to claims 1-4, 6, 8, 10-12, 14-17, and 20 above, and further in view of Payment et al. (US 2023/0353599)(hereinafter Payment)
Regarding claim 7, Murdoch, Shimoe, and Mital teach attach the first policy token to the first log in response to determining that the first policy token represents the policy that matches the certain attribute (Mital: see Col 19 lines 35-38, "Sidecar 110 receives an identification of information of interest in the data source(s) 102 and/or 104, at 902. Also at 902, policies related to the sensitive information are also received"; Shimoe: see Page 5 paragraph 0079 lines 8-16, “The destination determining unit 613 extracts information about devices that match the determined types of destination devices from the destination-information management table (operation S130 in FIG. 4) and creates a distribution-destination management table that associates each access control policy with one or more destination devices to which the access control policy is to be distributed (operation S140 in FIG. 4)”).
However, Murdoch, Shimoe, and Mital fail to teach identify a certain attribute of the first; search the policy tokens for a policy token representative of a policy that matches the certain attribute; determine, based at least in part on the search, that the first policy token represents a policy that matches the certain attribute.
Nevertheless, Payment-which is in the same field of endeavor-teaches identify a certain attribute of the first log (Payment: see Page 2 paragraph 0030m lines 14-21, “In various embodiments, the ABAC system identifies one or more attribute-based access control policies that match the request. An identity may be associated with the one or more attribute-based permissions (also referred to as attribute-based access control policies). For example, a role may be assigned to the identity and that the role corresponds to one or more attribute-based access control policies”; Page 2, paragraph 0035, lines 1-4, “In various embodiments, upon receiving the request, the ABAC system generates a graph that represents one or more attribute-based access control policies associated with the identity”); search the policy tokens for a policy token representative of a policy that matches the certain attribute (Payment: see Page 2 paragraph 0035 4-6, “The ABAC system may traverse the graph to identify an attribute-based access control policy that matches the request”); determine, based at least in part on the search, that the first policy token represents a policy that matches the certain attribute (Payment: see Page 2 paragraph 0036 lines 1-22, “In various embodiments, in order to provide access to the requested resource based on the attribute-based access control policy identified from the graph, the ABAC system identifies metadata associated with the resource, identifies a predicate associated with the attribute-based access control policy, and determines whether the metadata (e.g., resource metadata) satisfies the condition provided in the predicate. If the predicate result is true, indicating the condition is satisfied, the ABAC system determines the access control policy matches the request. Otherwise, the access control policy does not match”).
Murdoch, Shimoe, Mital, and Payment are analogous art because they are from the same field of endeavor, securing network protocols through the use of cryptographic arrangements. Before the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art to utilize Murdoch, Shimoe, and Mital’s inventions with Payment’s graph traversal and attribute access policy selection to select a policy token to apply. The suggestion/motivation for doing so would be to consistently enforce policy across different systems and resources.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to KELAH JANAE MCFARLAND-BARNES whose telephone number is (571)272-5953. The examiner can normally be reached Monday through Friday 8:00am until 4:00pm Central Time.
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, Lynn D Feild can be reached at 571-272-2092. 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.
/KELAH JANAE MCFARLAND-BARNES/Examiner, Art Unit 2431
/LYNN D FEILD/Supervisory Patent Examiner, Art Unit 2431
Prosecution Insights