DETAILED ACTION
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
The amendment filed 04/28/2026 has been fully considered and entered into record. Claims 1-20 remain pending in the application. Claims 1, 5, 10, and 14 have been amended.
Response to Arguments
Applicant's arguments with respect to claims 1-20 have been considered but are moot because the present rejection constitutes a new ground of rejection. The present rejection no longer relies only on YAN and Benedetti for the disputed limitations, but instead relies on YAN, Benedetti and Padmanabhan for teachings set forth in the rejection. Accordingly, Applicant’s arguments directed to the prior combination are not persuasive.
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 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.
Claims 1, 3, 4, 10, 12 and 13 are rejected under 35 U.S.C. 103 as being unpatentable over YAN et al. (US 2020/0057865A1) [hereinafter “YAN”] in view of Benedetti et al. (US12143395B2) [hereinafter “Benedetti”] and in view of Padmanabhan et al. (US 20210182423 A1) [hereinafter “Padmanabhan”]
As per claim 1, YAN discloses a method for managing data access to mitigate network security threats on a distributed ledger, wherein the method comprises:
receiving, by a data storage entity, a data access request sent from a client over a first interface, ( [YAN, [0029]]” In 310, an accessing request to the database system 200 is received from one member (referred to as “a first member”) among multiple members”)”) wherein data corresponding to the data access request is stored on the data storage entity; ( [YAN, [0023]]” the underlying database 210 is for storing data of multiple members and may be deployed in other position in a centralized or distributed way”) wherein the access permission verification request is for verifying whether the client has data access permission, ( [YAN, [0031]]” the accessing request received… is verified based on the rule set 222”)
sending, by the data storage entity, data corresponding to the data access request to the client over the first interface. ( [YAN, [0038], [0042]]”… the accessing request received in 310 is processed based on a verification result…” and “the SQL is executed in the relational database, so that the members may access related data in the relational database”)
Yan does not explicitly generating, by the data storage entity, an access permission verification request based on the data access request, and sending the access permission verification request to a distributed ledger node over a second interface, and the access permission verification request comprises an identifier of the client and/or an identifier of a user, and wherein the distributed ledger node is external to the data storage entity, and the second interface is inaccessible to the client such that the data storage entity isolates the distributed ledger node from direct data access requests by the client;
receiving, by the data storage entity, a first access permission verification response sent from the distributed ledger node over the second interface wherein the first access permission verification response indicates that the client has the data access permission;
However, Benedetti in the same field of endeavor discloses
generating, by the data storage entity, [an access permission verification request based on the data access request] ([ Benedetti, col.11 ln28-40, col.3 ln 45-50)” the access management governance orchestrator 400… This access management governance orchestrator 400 embodiment is described with reference to a system owner function 450, an auditor function 455, a user requesting system privileges function 460, and a system administrator function 465 that communicate via a blockchain 470” and “The process orchestrator determines who is the owner of the managed asset and/or the IT system, and routes the request to it”) and sending the access permission verification request to a distributed ledger node over a second interface, ([ Benedetti, col.11 ln28-40)”… a system owner function 450, an auditor function 455, a user requesting system privileges function 460, and a system administrator function 465 that communicate via a blockchain 470”) and the access permission verification request comprises an identifier of the client and/or an identifier of a user, ([ Benedetti, col.12 ln45-55)” RequestAccess (UID, ITSystemID, privileges, reason) AccessApproved (UID, ITSystemID, privileges,… RequestValidationP…GrantAccessP (ITSystemID)…”)
receiving, by the data storage entity, a first access permission verification response sent from the distributed ledger node over the second interface, ([ Benedetti, col.3 ln50-55)”… receives the access request, reviews the justification, decides to approve or reject the request, and returns the approved/rejected request to the process orchestrator;”) wherein the first access permission verification response indicates that the client has the data access permission; ([ Benedetti, col.12 ln45-55)” RequestAccess (UID, ITSystemID, privileges, reason) AccessApproved (UID, ITSystemID, privileges,… RequestValidationP…GrantAccessP (ITSystemID)…”).
Therefore, it would have been obvious before the effective filing date of the claimed invention for one of ordinary skill in the art to modify YAN’s storage unit/database to include an access permission verification request based on the data access request, and sending the access permission verification request to a distributed ledger node over a second interface, and the access permission verification request comprises an identifier of the client and/or an identifier of a user; a first access permission verification response sent from the distributed ledger node over the second interface wherein the first access permission verification response indicates that the client has the data access permission as suggested by Benedetti. One of ordinary skill in the art would have been motivated to do so because incorporating Benedetti’s distributed ledger-based access permission verification because doing so would provide a tamper-resistant and distributed mechanism for validating access permissions before granting access to requested data, thereby improving the integrity, security, and trustworthiness of authorization decisions while reducing the likelihood of unauthorized modification of access permissions and single-point failures.
The combination of Yan and Benedetti fails to disclose wherein the distributed ledger node is external to the data storage entity and the second interface is inaccessible to the client such that the data storage entity isolates the distributed ledger node from direct data access requests by the client;
However, Padmanabhan in the same field of endeavor discloses wherein the distributed ledger node is external to the data storage entity(Padmanabhan, [0171]” the host organization operates a participating node on the blockchain; and in which the blockchain operates external from the host organization and operates outside of the host organization's exclusive control”) and the second interface is inaccessible to the client such that the data storage entity isolates the distributed ledger node from direct data access requests by the client; (Padmanabhan, [0088],[0090] [0127]” the query interface 180 provides interoperability with the blockchain services interface 240, thus permitting the host organization 110 to conduct transactions with either the database system 130 via the query interface 180 or to transact blockchain transactions onto a connected blockchain” and “Host organization 110 may implement a request interface 176…via web-server 175 or as a stand-alone interface to receive… or other requests 115 from the user client devices. Authenticator 140 operates on behalf of the host organization to verify, authenticate, and otherwise credential users attempting to gain access to the host organization” and also “the access control layer 151…provides certain access rights and restrictions for private and permissioned blockchains that are not fully open to public access.”).
Therefore, it would have been obvious before the effective filing date of the claimed invention for one of ordinary skill in the art to modify YAN’s storage unit/database to include an access permission verification request based on the data access request, and sending the access permission verification request to a distributed ledger node over a second interface, and the access permission verification request comprises an identifier of the client and/or an identifier of a user; a first access permission verification response sent from the distributed ledger node over the second interface wherein the first access permission verification response indicates that the client has the data access permission as suggested by Benedetti to further include wherein the distributed ledger node is external to the data storage entity and the second interface is inaccessible to the client such that the data storage entity isolates the distributed ledger node from direct data access requests by the client as taught by Padmanabhan. One of ordinary skill in the art would have been motivated to do so because such an architecture isolates distributed ledger nodes from direct client access while maintaining communication through the data storage entity. This improves security by preventing clients from directly interacting with permissioned blockchain nodes, reducing the attack surface, enforcing centralized access requests to be mediated by the data storage entity.
As per claim 3, the references as combined above disclose the method according to claim 1. YAN further discloses wherein the generating, by the data storage entity, an access permission verification request based on the data access request comprises: generating, by the data storage entity, ( [YAN, [0029]]” In 310, an accessing request to the database system 200 is received from one member (referred to as “a first member”) among multiple members”… According to the implementation of the present disclosure, in 330 it may be judged based on the rule set 222 whether the first member has the right to execute the requested operation to a corresponding object. If it is confirmed the accessing request conforms to related regulations in the rule set 222, then the first member is allowed to execute the accessing request; otherwise, the first member may be rejected to execute the accessing request.” The Examiner interprets “allowed to execute the accessing request” in the context of a database access request as necessarily including retrieving and proving the requested corresponding data to the requesting member). Yan does not disclose the access permission verification request based on a smart contract and the data access request. However, Benedetti in the same field of endeavor discloses the access permission verification request based on a smart contract and the data access request ([ Benedetti, [69]” The executing of the smart contract may trigger a trusted modification(s) to a state of a digital blockchain ledger. The modification(s) to the blockchain ledger caused by the smart contract execution may be automatically replicated throughout the distributed network of blockchain peers through one or more consensus protocols in some embodiments.”)
Therefore, it would have been obvious before the effective filing date of the claimed invention for one of ordinary skill in the art to modify YAN to include the access permission verification request based on a smart contract and the data access request as suggested by Benedetti. One of ordinary skill in the art would have been motivated to do so because incorporating smart contract-based authorization logic deployed on a distributed ledger automates access approval, enforces authorization policies, and improves auditability and trustworthiness of access control decisions.
As per claim 4, the references as combined above disclose according to claim 1. YAN further discloses wherein the method further comprises: receiving, by the data storage entity, a data update request sent from the client;( [YAN, [0029]]” In 310, an accessing request to the database system 200 is received from one member (referred to as “a first member”) among multiple members”). Yan further discloses updating, by the data storage entity, the data corresponding to the client. ( [YAN, [0039]]” According to the implementation of the present disclosure, in 330 it may be judged based on the rule set 222 whether the first member has the right to execute the requested operation to a corresponding object. If it is confirmed the accessing request conforms to related regulations in the rule set 222, then the first member is allowed to execute the accessing request; otherwise, the first member may be rejected to execute the accessing request.” The Examiner interprets “allowed to execute the accessing request” in the context of a database access request as necessarily including retrieving and proving the requested corresponding data to the requesting member) YAN does not disclose generating, by the data storage entity, an update permission verification request based on the data update request, and sending the update permission verification request to the distributed ledger node, wherein the update permission verification request is for verifying whether the client has data update permission, and the update permission verification request carries the identifier of the client and/or the identifier of the user; receiving, by the data storage entity, a first update permission verification response sent from the distributed ledger node, wherein the first update permission verification response indicates that the client has the data update permission. However, Benedetti in the same field of endeavor discloses generating, by the data storage entity, an update permission verification request based on the data update request, ([ Benedetti, (Abstract)” querying an authorization for accessing the resource from an access manager, and in response to the querying of the authorization, requesting an access control policy update to grant the access to the managed resource ”) and sending the update permission verification request to the distributed ledger node, ([ Benedetti, [claim1” generating a transaction record; and adding the transaction record to a distributed ledger, wherein the distributed ledger simultaneously maintains the transaction record at multiple nodes throughout the blockchain network, wherein requesting the access control policy update comprises executing a smart contract that processes transactions in the distributed ledger.” The Examiner interprets “adding the transaction record to a distributed ledger” as necessarily including transmitting the transaction record to at least one distributed ledger node for validation and smart contract execution, which constitutes sending the update permission verification request to the distributed ledger node.) wherein the update permission verification request is for verifying whether the client has data update permission, ([ Benedetti, (Abstract)”… requesting an access control policy update to grant the access to the managed resource. Receiving the request, querying the authorization, and requesting the access control policy”) and the update permission verification request carries the identifier of the client and/or the identifier of the user;([ Benedetti, (col.3 ln45-55)” A user seeking authorization to a managed asset in an IT system submits a request for access, typically providing a justification to the access management process orchestrator…The process orchestrator determines who is the owner of the managed asset and/or the IT system, and routes the request to it;”) receiving, by the data storage entity, a first update permission verification response sent from the distributed ledger node, ([ Benedetti, (col.5 ln50-60)]” transactions may be guaranteed to be accepted in the distributed ledger if and only if the network reached consensus that they are valid” ) wherein the first update permission verification response indicates that the client has the data update permission;([ Benedetti, (col.29 ln60-65 ), (col.16, ln35-40)]” receiving an approval of the request for the access control policy update from the owner of the information system; and in response to the approval of the request for the access control policy update… ” and “The proposal response 592 may then be sent back to the client 560, along with an endorsement signature, if approved.”).
Therefore, it would have been obvious before the effective filing date of the claimed invention for one of ordinary skill in the art to modify YAN to include generating, by the data storage entity, an update permission verification request based on the data update request, and sending the update permission verification request to the distributed ledger node, wherein the update permission verification request is for verifying whether the client has data update permission, and the update permission verification request carries the identifier of the client and/or the identifier of the user; receiving, by the data storage entity, a first update permission verification response sent from the distributed ledger node, wherein the first update permission verification response indicates that the client has the data update permission as suggested by Benedetti. One of ordinary skill in the art would have been motivated to do so because Benedetti teaches using a distributed ledger based access management governance orchestrator to validate and enforce authorization decisions in a tamper-resistant and auditable manner, thereby improving security, transparency, and resistance to unauthorized privilege escalation when managing access and update permissions.
As per claim 10, YAN discloses a communication apparatus, comprising a processor coupled to a memory storing instructions, which when executed by the processor, cause the communication apparatus to perform operations comprising:
receiving a data access request sent from a client over a first interface, ( [YAN, [0029]]” In 310, an accessing request to the database system 200 is received from one member (referred to as “a first member”) among multiple members”)”) wherein data corresponding to the data access request is stored on the communication apparatus; ( [YAN, [0023]]” the underlying database 210 is for storing data of multiple members and may be deployed in other position in a centralized or distributed way”)
sending data corresponding to the data access request to the client over the first interface. ( [YAN, [0038], [0042]]”… the accessing request received in 310 is processed based on a verification result…” and “the SQL is executed in the relational database, so that the members may access related data in the relational database”)
Yan does not disclose generating an access permission verification request based on the data access request, and sending the access permission verification request to a distributed ledger node over a second interface, wherein the access permission verification request is for verifying whether the client has data access permission, and the access permission verification request comprises an identifier of the client and/or an identifier of a user, and wherein the distributed ledger node is external to the data storage entity and the second interface is inaccessible to the client such that the data storage entity isolates the distributed ledger node from direct data access requests by the client;
receiving a first access permission verification response sent from the distributed ledger node over the second interface, wherein the first access permission verification response indicates that the client has the data access permission;
However, Benedetti in the same field of endeavor discloses
generating, by the data storage entity, [an access permission verification request based on the data access request] ([ Benedetti, col.11 ln28-40, col.3 ln 45-50)” the access management governance orchestrator 400… This access management governance orchestrator 400 embodiment is described with reference to a system owner function 450, an auditor function 455, a user requesting system privileges function 460, and a system administrator function 465 that communicate via a blockchain 470” and “The process orchestrator determines who is the owner of the managed asset and/or the IT system, and routes the request to it”) and sending the access permission verification request to a distributed ledger node over a second interface, ([ Benedetti, col.11 ln28-40)”… a system owner function 450, an auditor function 455, a user requesting system privileges function 460, and a system administrator function 465 that communicate via a blockchain 470”) and the access permission verification request comprises an identifier of the client and/or an identifier of a user, ([ Benedetti, col.12 ln45-55)” RequestAccess (UID, ITSystemID, privileges, reason) AccessApproved (UID, ITSystemID, privileges,… RequestValidationP…GrantAccessP (ITSystemID)…”)
receiving, by the data storage entity, a first access permission verification response sent from the distributed ledger node over the second interface, ([ Benedetti, col.3 ln50-55)”… receives the access request, reviews the justification, decides to approve or reject the request, and returns the approved/rejected request to the process orchestrator;”) wherein the first access permission verification response indicates that the client has the data access permission; ([ Benedetti, col.12 ln45-55)” RequestAccess (UID, ITSystemID, privileges, reason) AccessApproved (UID, ITSystemID, privileges,… RequestValidationP…GrantAccessP (ITSystemID)…”).
Therefore, it would have been obvious before the effective filing date of the claimed invention for one of ordinary skill in the art to modify YAN’s storage unit/database to include an access permission verification request based on the data access request, and sending the access permission verification request to a distributed ledger node over a second interface, and the access permission verification request comprises an identifier of the client and/or an identifier of a user; a first access permission verification response sent from the distributed ledger node over the second interface wherein the first access permission verification response indicates that the client has the data access permission as suggested by Benedetti. One of ordinary skill in the art would have been motivated to do so because incorporating Benedetti’s distributed ledger-based access permission verification because doing so would provide a tamper-resistant and distributed mechanism for validating access permissions before granting access to requested data, thereby improving the integrity, security, and trustworthiness of authorization decisions while reducing the likelihood of unauthorized modification of access permissions and single-point failures.
The combination of Yan and Benedetti fails to disclose wherein the distributed ledger node is external to the data storage entity and the second interface is inaccessible to the client such that the data storage entity isolates the distributed ledger node from direct data access requests by the client;
However, Padmanabhan in the same field of endeavor discloses wherein the distributed ledger node is external to the data storage entity(Padmanabhan, [0171]” the host organization operates a participating node on the blockchain; and in which the blockchain operates external from the host organization and operates outside of the host organization's exclusive control”) and the second interface is inaccessible to the client such that the data storage entity isolates the distributed ledger node from direct data access requests by the client; (Padmanabhan, [0088],[0090] [0127]” the query interface 180 provides interoperability with the blockchain services interface 240, thus permitting the host organization 110 to conduct transactions with either the database system 130 via the query interface 180 or to transact blockchain transactions onto a connected blockchain” and “Host organization 110 may implement a request interface 176…via web-server 175 or as a stand-alone interface to receive… or other requests 115 from the user client devices. Authenticator 140 operates on behalf of the host organization to verify, authenticate, and otherwise credential users attempting to gain access to the host organization” and also “the access control layer 151…provides certain access rights and restrictions for private and permissioned blockchains that are not fully open to public access.”).
Therefore, it would have been obvious before the effective filing date of the claimed invention for one of ordinary skill in the art to modify YAN’s storage unit/database to include an access permission verification request based on the data access request, and sending the access permission verification request to a distributed ledger node over a second interface, and the access permission verification request comprises an identifier of the client and/or an identifier of a user; a first access permission verification response sent from the distributed ledger node over the second interface wherein the first access permission verification response indicates that the client has the data access permission as suggested by Benedetti to further include wherein the distributed ledger node is external to the data storage entity and the second interface is inaccessible to the client such that the data storage entity isolates the distributed ledger node from direct data access requests by the client as taught by Padmanabhan. One of ordinary skill in the art would have been motivated to do so because such an architecture isolates distributed ledger nodes from direct client access while maintaining communication through the data storage entity. This improves security by preventing clients from directly interacting with permissioned blockchain nodes, reducing the attack surface, enforcing centralized access requests to be mediated by the data storage entity.
As per claim 12, the substance of the claimed invention is identical or substantially similar to that of claim 3. Accordingly, this claim is rejected under the same rationale.
As per claim 13, the substance of the claimed invention is identical or substantially similar to that of claim 4. Accordingly, this claim is rejected under the same rationale.
Claims 2, 11 are rejected under 35 U.S.C. 103 as being unpatentable over YAN et al. (US 2020/0057865A1) [hereinafter “YAN”] in view of Benedetti et al. (US12143395B2) [hereinafter “Benedetti”] and in view of Padmanabhan et al. (US 20210182423 A1) [hereinafter “Padmanabhan”] as applied to claim 1, and further in view of Hegde et al. (US 20210056082 A1) [hereinafter “Hegde”].
As per claim 2, the references as combined above discloses the method according to claim 1. The combination does not disclose wherein the method further comprises: sending, by the data storage entity, a data return success message to the distributed ledger node, wherein the data return success message carries data access transaction information of the client. However, Hegde in the same field of endeavor discloses wherein the method further comprises: sending, by the data storage entity, a data return success message node ([ Hegde, [0053], [0059], [abstract]” In response to the PUT RESOURCE ID message a SUCCESS OR FAILURE message will be returned to storage system access point 320. If the UUID of the resource to be written is located by IAM module 330, either because it already existed or because it was newly created, the message will indicate SUCCESS” [0053], “Notification service 315 is, in at least one embodiment, a push notification service that receives notification messages from storage system access point 320, and provides those notifications to client 310. Notification service 315 can forward notifications received without substantive modification, so that the content of received notifications is maintained, even if the message is repackaged for transmission.”[0059], “In response to that the first data has been successfully accessed, and that the information corresponding to the first access request has been successfully recorded by the external audit system, notifying the client device that the first access request has been successfully completed.”) to the distributed ledger([ Hedge, [0048]-0049]” In some embodiments, a device functioning as a storage system storage point 340 is included in Blockchain network 350, for example as a peer…. Blockchain network 350, like other Blockchain networks is a decentralized, distributed network used to implement digital records of transactions across many computers, so that any involved record cannot be altered retroactively, without the alteration of all subsequent blocks. Blockchain network 350 includes peers and orderers, which can be implemented using devices and modules internal to a data storage system served by storage system access point 320, or some combination thereof. For example, in at least one embodiment, Blockchain network 350 includes external audit system 38 (FIG. 1), which in addition to its other functions operates as a peer or an orderer in Blockchain network 350, and storage system access point 320, which in addition to its other functions operates as a peer in Blockchain network 350”.
wherein the data return success message carries data access transaction information of the client ([ Hedge, [0039]” In one or more embodiments, the record stored by the external audit system is a block having the following format:
TABLE-US-00001 { Resource name:<Name of the compute or storage resource: e.g. A bucket or object in object storage> Resource UUID: <Unique ID for the resource for the life of the resource> Type of Access: <Granted access to the resource: E.g. Read or Write to a bucket or object in object storage> Timestamp: <UTC time of request> Username: <The user who was granted access> Client Identifier: <UUID> Client IP address: <Identifier for the address from where the request was received> XYZ-Metadata: <Any user provided metadata in the request> Hash of previous block: <Hash of the previous block in the Blockchain> }”).
Therefore, it would have been obvious before the effective filing date of the claimed invention for one of ordinary skill in the art to modify the system created by combination of YAN, Benedetti and Padmanabhan to include sending, by the data storage entity, a data return success message to the distributed ledger node, wherein the data return success message carries data access transaction information of the client as suggested by Hegde. One of ordinary skill in the art would have been motivated to do so because incorporating immutable audit logging of client data access transactions within the distributed ledger improves integrity and traceability of access events.
As per claim 11, the substance of the claimed invention is identical or substantially similar to that of claim 2. Accordingly, this claim is rejected under the same rationale.
Claims 5, 7, 9, 14, 16-18 are rejected under 35 U.S.C. 103 as being unpatentable over Padmanabhan et al(US 20210182423 A1) [hereinafter “Padmanabhan”] in view Collinson et al. (US 12107856B2) [hereinafter “Collinson”] and in view of Benedetti et al. (US12143395B2) [hereinafter “Benedetti”].
As per claim 5, Padmanabhan discloses a method for managing data access to mitigate network security threats on a distributed ledger, wherein the method comprises:
receiving, by a distributed ledger node external to the data storage entity, (Padmanabhan, [0171]” the host organization operates a participating node on the blockchain; and in which the blockchain operates external from the host organization and operates outside of the host organization's exclusive control”)wherein the second interface is inaccessible to the client such that the data storage entity isolates the distributed ledger node from direct data access requests by the client; (Padmanabhan, [0088],[0090] [0127]” the query interface 180 provides interoperability with the blockchain services interface 240, thus permitting the host organization 110 to conduct transactions with either the database system 130 via the query interface 180 or to transact blockchain transactions onto a connected blockchain” and “Host organization 110 may implement a request interface 176…via web-server 175 or as a stand-alone interface to receive… or other requests 115 from the user client devices. Authenticator 140 operates on behalf of the host organization to verify, authenticate, and otherwise credential users attempting to gain access to the host organization” and also “the access control layer 151…provides certain access rights and restrictions for private and permissioned blockchains that are not fully open to public access.”).
Padmanabhan does not disclose an access permission verification request sent from a data storage entity over a second interface, wherein the access permission verification request is for verifying whether a client, which communicates with the data storage entity over a first interface, has data access permission to access data stored on the data storage entity,
verifying, by the distributed ledger node based on the identifier of the client and/or the identifier of the user and the distributed ledger whether the client has the data access permission, and
sending, by the distributed ledger node, a first access permission verification response to the data storage entity over the second interface in response to the verifying that the client has the data access permission, wherein the first access permission verification response indicates that the client has the data access permission.
However, Benedetti in the same field of endeavor discloses an access permission verification request sent from a data storage entity over a second interface, ([ Benedetti, col.11 ln28-40)”… a system owner function 450, an auditor function 455, a user requesting system privileges function 460, and a system administrator function 465 that communicate via a blockchain 470”) wherein the access permission verification request is for verifying whether a client, which communicates with the data storage entity([ Benedetti, col.3 ln50-55)”… receives the access request, reviews the justification, decides to approve or reject the request, and returns the approved/rejected request to the process orchestrator;”) over a first interface, has data access permission to access data stored on the data storage entity, ([ Benedetti, col.12 ln45-55)” RequestAccess (UID, ITSystemID, privileges, reason) AccessApproved (UID, ITSystemID, privileges,… RequestValidationP…GrantAccessP (ITSystemID)…”)
verifying, by the distributed ledger node based on the identifier of the client and/or the identifier of the user and the distributed ledger, ([ Benedetti, col.3 ln50-55)”… receives the access request, reviews the justification, decides to approve or reject the request, and returns the approved/rejected request to the process orchestrator;”) whether the client has the data access permission, ([ Benedetti, col.12 ln45-55)” RequestAccess (UID, ITSystemID, privileges, reason) AccessApproved (UID, ITSystemID, privileges,… RequestValidationP…GrantAccessP (ITSystemID)…”).
and sending, by the distributed ledger node, a first access permission verification response to the data storage entity over the second interface in response to the verifying that the client has the data access permission, ([ Benedetti, col.3 ln50-55)”… receives the access request, reviews the justification, decides to approve or reject the request, and returns the approved/rejected request to the process orchestrator;”) wherein the first access permission verification response indicates that the client has the data access permission. ([ Benedetti, col.12 ln45-55)” RequestAccess (UID, ITSystemID, privileges, reason) AccessApproved (UID, ITSystemID, privileges,… RequestValidationP…GrantAccessP (ITSystemID)…”).
Therefore, it would have been obvious before the effective filing date of the claimed invention for one of ordinary skill in the art to modify Padmanabhan to include an access permission verification request sent from a data storage entity over a second interface, wherein the access permission verification request is for verifying whether a client, which communicates with the data storage entity over a first interface, has data access permission to access data stored on the data storage entity,
verifying, by the distributed ledger node based on the identifier of the client and/or the identifier of the user and the distributed ledger whether the client has the data access permission, and sending, by the distributed ledger node, a first access permission verification response to the data storage entity over the second interface in response to the verifying that the client has the data access permission, wherein the first access permission verification response indicates that the client has the data access permission as suggested by Benedetti. One of ordinary skill in the art would have been motivated to do so because the combination merely applies a known access permission verification mechanism to the known blockchain access control architecture of Padmanabhan to obtain the predictable result of verifying user permissions before permitting data access.
The combination of Padmanabhan and Benedetti fails to disclose wherein the distributed ledger stores a data access policy of the client and/or a data access policy of the user;
However, Collinson in the same field of endeavor discloses wherein the distributed ledger stores a data access policy of the client and/or a data access policy of the user; ([Collinson, (col.5 ln 24-44)]”… encrypted set of centralized access permissions…to immutably record elements of interaction data onto the permissioned distributed ledger…or to query the permissioned distributed ledger to access and obtain selected elements of recorded interaction data consistent with a granted access permission”).
Therefore, it would have been obvious before the effective filing date of the claimed invention for one of ordinary skill in the art to modify Padmanabhan to include an access permission verification request sent from a data storage entity over a second interface, wherein the access permission verification request is for verifying whether a client, which communicates with the data storage entity over a first interface, has data access permission to access data stored on the data storage entity,
verifying, by the distributed ledger node based on the identifier of the client and/or the identifier of the user and the distributed ledger whether the client has the data access permission, and sending, by the distributed ledger node, a first access permission verification response to the data storage entity over the second interface in response to the verifying that the client has the data access permission, wherein the first access permission verification response indicates that the client has the data access permission as suggested by Benedetti to further include wherein the distributed ledger stores a data access policy of the client and/or a data access policy of the user as taught by Collinson. One of ordinary skill in the art would have been motivated to do so because storing access policies on the permissioned distributed ledger would improve the reliability, consistency, and security of access permission verification by providing an immutable, distributed repository of access permissions.
As per claim 7, the references as combined above disclose the method according to claim 5. Collinson further discloses wherein the sending, by the distributed ledger node, a first access permission verification response to the data storage entity in response to the client has the data access permission comprises: sending, by the distributed ledger node, the first access permission verification response to the data storage entity ([Collinson, (col.21, ln5-25)]” Based on these determinations, comparison module 240 may generate confirmation data 242 indicative of the permission granted participant system 110 to record the payload 214 (e.g., that includes elements of interaction data 202 and 208) within an additional ledger block of permissioned distributed ledger 180. In other instances, not illustrated in FIG. 2B, if comparison module 240 were to establish that the default permissions specified within decrypted permissioning data 238 do not permit participant system 110 to record any elements of interaction data onto permissioned distributed ledger 280, or that one or more participant-specific permissions restrict a default recordation permission granted participant system 110, comparison module 240 may generate one or more additional elements of confirmation data indicate of the denial of permission for participant system 110 to record the payload 214 within the additional ledger block. In some instances, comparison module 240 may route confirmation data 242 back to executed initiation module 232.”). Collinson does not disclose generating, by the distributed ledger node, the first access permission verification response based on a smart contract in response to the client has the data access permission. However, Benedetti in the same field of endeavor discloses generating, by the distributed ledger node, the first access permission verification response based on a smart contract in response to the client has the data access permission ([ Benedetti, [col.4 ln20-25]” the access management governance orchestrator may advantageously include a distributed ledger (e.g., blockchain) that will disperse the authority and ensure full transparency on the operations by all the involved parties by simultaneously maintaining transaction records at multiple points throughout a network. In particular, some embodiments may provide an access management governance process for orchestrating how to request, approve, grant, revoke, validate, etc., changes to the authorization policies, including access management governance orchestrator interfaces each of the local IT system access control systems to request changes to the authorization policies.”).
Therefore, it would have been obvious before the effective filing date of the
claimed invention for one of ordinary skill in the art to modify Collinson to include generating, by the distributed ledger node, the first access permission verification response based on a smart contract in response to the client has the data access permission. However, Benedetti in the same field of endeavor discloses generating, by the distributed ledger node, the first access permission verification response based on a smart contract in response to the client has the data access permission as suggested by Benedetti. One of ordinary skill in the art would have been motivated to do so because incorporating smart contract based authorization logic deployed on a distributed ledger automates access approval, enforces authorization policies , and improves auditability and trustworthiness of access control decisions.
As per claim 9, the references as combined above the method according to claim 5. Collinson further discloses wherein the method comprises: receiving, by the distributed ledger node, an update permission verification request sent from the data storage entity ([Collinson, (col.18 ln30-35)]” CA system 152 (and each additional or alternate one of CA systems 150) may receive recordation request 216 through a corresponding programmatic interface, such as application programming interface (API) 228, and may route recordation request 216 to a verification module 230.”) wherein the update permission verification request is for verifying whether the client has data update permission, ([Collinson, (col.12 ln15-20)-( col.12 ln50-56)]”..permissioning data 164 that characterize an ability of the participant associated with each of the participant systems …recordation permissions granted to that corresponding participant class by the centralized authority and the update permission verification request carries the identifier of the client and/or the identifier of the user; ([Collinson, (col.18, ln1-5)]” In addition, executed distributed interaction module 206 may also perform operations that package, into corresponding portions of recordation request 216, participant data 224 that uniquely identifies participant system 110 ” ) verifying, by the distributed ledger node based on the identifier of the client and/or the identifier of the user and the distributed ledger, whether the client has the data update permission, wherein the distributed ledger stores a data update policy of the client and/or a data update policy of the user; ([Collinson, (col.12 ln25-30)]” In some examples, each of CA systems 150, including CA system 152, may represent a node (or “peer” system) within a permissioned distributed-ledger network that establishes, maintains, and updates permissioned distributed ledger 180 using any of the consensus-based processes described herein.” )and sending a first update permission verification response to the data storage entity in response to the client has the data update permission, ([Collinson, (col.23 ln15-24)]” CA system 152 may perform additional operations that generate an updated permissioned distributed ledger 256 (e.g., a latest, longest version of the permissioned distributed ledger) by appending ledger block 252 to the ledger blocks of permissioned distributed ledger” ) wherein the first update permission verification response indicates that the client has the data update permission. ([Collinson, (col.23 ln25-30)]” In certain aspects, CA system 152 may broadcast evidence of the calculated proof-of-work or proof-of-stake to other ones of CA systems 150 across network 120 (e.g., as consensus data 260”).
As per claim 14, Padmanabhan discloses a communication apparatus, comprising a processor coupled to a memory storing instructions, which when executed by the processor, cause the communication apparatus to perform operations comprising:
wherein the distributed ledger node is external to the data storage entity (Padmanabhan, [0171]” the host organization operates a participating node on the blockchain; and in which the blockchain operates external from the host organization and operates outside of the host organization's exclusive control”) and the second interface is inaccessible to the client such that the data storage entity isolates the distributed ledger node from direct data access requests by the client; (Padmanabhan, [0088],[0090] [0127]” the query interface 180 provides interoperability with the blockchain services interface 240, thus permitting the host organization 110 to conduct transactions with either the database system 130 via the query interface 180 or to transact blockchain transactions onto a connected blockchain” and “Host organization 110 may implement a request interface 176…via web-server 175 or as a stand-alone interface to receive… or other requests 115 from the user client devices. Authenticator 140 operates on behalf of the host organization to verify, authenticate, and otherwise credential users attempting to gain access to the host organization” and also “the access control layer 151…provides certain access rights and restrictions for private and permissioned blockchains that are not fully open to public access.”).
Padmanabhan does not disclose receiving an access permission verification request sent from a data storage entity over a second interface, wherein the access permission verification request is for verifying whether a client, which communicates with the data storage entity over a first interface, has data access permission to access data stored on the data storage entity, ([ Benedetti, col.3 ln50-55)”… receives the access request, reviews the justification, decides to approve or reject the request, and returns the approved/rejected request to the process orchestrator;”) and the access permission verification request carries an identifier of the client and/or an identifier of a user,
verify based on the identifier of the client and/or the identifier of the user and a distributed ledger, whether the client has the data access permission, wherein the distributed ledger stores a data access policy of the client and/or a data access policy of the user; and send a first access permission verification response to the data storage entity over the second interface in response to the client has the data access permission, wherein the first access permission verification response indicates that the client has the data access permission.
However, Benedetti in the same field of endeavor discloses receiving an access permission verification request sent from a data storage entity over a second interface, ([ Benedetti, col.11 ln28-40)”… a system owner function 450, an auditor function 455, a user requesting system privileges function 460, and a system administrator function 465 that communicate via a blockchain 470”) wherein the access permission verification request is for verifying whether a client, which communicates with the data storage entity ([ Benedetti, col.3 ln50-55)”… receives the access request, reviews the justification, decides to approve or reject the request, and returns the approved/rejected request to the process orchestrator;”) over a first interface, has data access permission to access data stored on the data storage entity, ([ Benedetti, col.12 ln45-55)” RequestAccess (UID, ITSystemID, privileges, reason) AccessApproved (UID, ITSystemID, privileges,… RequestValidationP…GrantAccessP (ITSystemID)…”) and the access permission verification request carries an identifier of the client and/or an identifier of a user, verify based on the identifier of the client and/or the identifier of the user and a distributed ledger, ([ Benedetti, col.3 ln50-55)”… receives the access request, reviews the justification, decides to approve or reject the request, and returns the approved/rejected request to the process orchestrator;”) whether the client has the data access permission, ([ Benedetti, col.12 ln45-55)” RequestAccess (UID, ITSystemID, privileges, reason) AccessApproved (UID, ITSystemID, privileges,… RequestValidationP…GrantAccessP (ITSystemID)…”) and
send a first access permission verification response to the data storage entity over the second interface in response to the client has the data access permission, ([ Benedetti, col.3 ln50-55)”… receives the access request, reviews the justification, decides to approve or reject the request, and returns the approved/rejected request to the process orchestrator;”) wherein the first access permission verification response indicates that the client has the data access permission. ([ Benedetti, col.12 ln45-55)” RequestAccess (UID, ITSystemID, privileges, reason) AccessApproved (UID, “).
Therefore, it would have been obvious before the effective filing date of the claimed invention for one of ordinary skill in the art to modify Padmanabhan to include an access permission verification request sent from a data storage entity over a second interface, wherein the access permission verification request is for verifying whether a client, which communicates with the data storage entity over a first interface, has data access permission to access data stored on the data storage entity,
verifying, by the distributed ledger node based on the identifier of the client and/or the identifier of the user and the distributed ledger whether the client has the data access permission, and sending, by the distributed ledger node, a first access permission verification response to the data storage entity over the second interface in response to the verifying that the client has the data access permission, wherein the first access permission verification response indicates that the client has the data access permission as suggested by Benedetti. One of ordinary skill in the art would have been motivated to do so because the combination merely applies a known access permission verification mechanism to the known blockchain access control architecture of Padmanabhan to obtain the predictable result of verifying user permissions before permitting data access.
The combination of Padmanabhan and Benedetti fails to disclose wherein the distributed ledger stores a data access policy of the client and/or a data access policy of the user;
However, Collinson in the same field of endeavor discloses wherein the distributed ledger stores a data access policy of the client and/or a data access policy of the user; ([Collinson, (col.5 ln 24-44)]”… encrypted set of centralized access permissions…to immutably record elements of interaction data onto the permissioned distributed ledger…or to query the permissioned distributed ledger to access and obtain selected elements of recorded interaction data consistent with a granted access permission”).
Therefore, it would have been obvious before the effective filing date of the claimed invention for one of ordinary skill in the art to modify Padmanabhan to include an access permission verification request sent from a data storage entity over a second interface, wherein the access permission verification request is for verifying whether a client, which communicates with the data storage entity over a first interface, has data access permission to access data stored on the data storage entity,
verifying, by the distributed ledger node based on the identifier of the client and/or the identifier of the user and the distributed ledger whether the client has the data access permission, and sending, by the distributed ledger node, a first access permission verification response to the data storage entity over the second interface in response to the verifying that the client has the data access permission, wherein the first access permission verification response indicates that the client has the data access permission as suggested by Benedetti to further include wherein the distributed ledger stores a data access policy of the client and/or a data access policy of the user as taught by Collinson. One of ordinary skill in the art would have been motivated to do so because storing access policies on the permissioned distributed ledger would improve the reliability, consistency, and security of access permission verification by providing an immutable, distributed repository of access permissions.
As per claim 16, the substance of the claimed invention is identical or substantially similar to that of claim 7. Accordingly, this claim is rejected under the same rationale.
As per claim 17, the substance of the claimed invention is identical or substantially similar to that of claim 8. Accordingly, this claim is rejected under the same rationale.
As per claim 18, the substance of the claimed invention is identical or substantially similar to that of claim 9. Accordingly, this claim is rejected under the same rationale.
Claims 6, 8 and 15 are rejected under 35 U.S.C. 103 as being unpatentable over Padmanabhan et al(US 20210182423 A1) [hereinafter “Padmanabhan”] in view Collinson et al. (US 12107856B2) [hereinafter “Collinson”] and in view of Benedetti et al. (US12143395B2) [hereinafter “Benedetti”]as applied to claims 5, 14 and further in view of Hegde et al. (US 20210056082 A1) [hereinafter “Hegde”].
As per claim 6, the references as combined above disclose the method according to claim 5. The combination fails to disclose wherein the method further comprises: receiving, by the distributed ledger node, a data return success message sent by the data storage entity, wherein the data return success message carries data access transaction information of the client; and recording, by the distributed ledger node, the data access transaction information of the client in the distributed ledger. However, Hegde in the same field of endeavor discloses wherein the method further comprises: receiving, by the distributed ledger node, a data return success message sent by the data storage entity, ([ Hegde, [0053], [0059], [abstract]” In response to the PUT RESOURCE ID message a SUCCESS OR FAILURE message will be returned to storage system access point 320. If the UUID of the resource to be written is located by IAM module 330, either because it already existed or because it was newly created, the message will indicate SUCCESS” [0053], “Notification service 315 is, in at least one embodiment, a push notification service that receives notification messages from storage system access point 320 and provides those notifications to client 310. Notification service 315 can forward notifications received without substantive modification, so that the content of received notifications is maintained, even if the message is repackaged for transmission.”[0059], “In response to that the first data has been successfully accessed, and that the information corresponding to the first access request has been successfully recorded by the external audit system, notifying the client device that the first access request has been successfully completed.”) wherein the data return success message carries data access transaction information of the client; ([ Hedge, [0039]” In one or more embodiments, the record stored by the external audit system is a block having the following format:
TABLE-US-00001 { Resource name:<Name of the compute or storage resource: e.g. A bucket or object in object storage> Resource UUID: <Unique ID for the resource for the life of the resource> Type of Access: <Granted access to the resource: E.g. Read or Write to a bucket or object in object storage> Timestamp: <UTC time of request> Username: <The user who was granted access> Client Identifier: <UUID> Client IP address: <Identifier for the address from where the request was received> XYZ-Metadata: <Any user provided metadata in the request> Hash of previous block: <Hash of the previous block in the Blockchain> }”). and recording, by the distributed ledger node, the data access transaction information of the client in the distributed ledger ([ Hedge, [0048]-0049]” In some embodiments, a device functioning as a storage system storage point 340 is included in Blockchain network 350, for example as a peer…. Blockchain network 350, like other Blockchain networks is a decentralized, distributed network used to implement digital records of transactions across many computers, so that any involved record cannot be altered retroactively, without the alteration of all subsequent blocks. Blockchain network 350 includes peers and orderers, which can be implemented using devices and modules internal to a data storage system served by storage system access point 320, or some combination thereof. For example, in at least one embodiment, Blockchain network 350 includes external audit system 38 (FIG. 1), which in addition to its other functions operates as a peer or an orderer in Blockchain network 350, and storage system access point 320, which in addition to its other functions operates as a peer in Blockchain network 350”.)
Therefore, it would have been obvious before the effective filing date of the claimed invention for one of ordinary skill in the art to modify the system created by combination of Padmanabhan, Collinson and Benedetti to include receiving, by the distributed ledger node, a data return success message sent by the data storage entity, wherein the data return success message carries data access transaction information of the client; and recording, by the distributed ledger node, the data access transaction information of the client in the distributed ledger as taught by Hegde. One of ordinary skill in the art would have been motivated to do so because incorporating immutable audit logging of client data access transactions within the distributed ledger improves integrity and traceability of access events.
As per claim 8, the combination of Padmanabhan, Collinson and Benedetti discloses the method according to claim 5. Collinson as modified fails to disclose wherein the method comprises: sending, by the distributed ledger node, a second access permission verification response to the data storage entity in response to the client does not have the data access permission, wherein the second access permission verification response indicates that the client does not have the data access permission.
However, Hegde in the same field of endeavor discloses wherein the method comprises: sending, by the distributed ledger node, a second access permission verification response to the data storage entity in response to the client does not have the data access permission, wherein the second access permission verification response indicates that the client does not have the data access permission.([Hedge, [0050], [0011]” The atomic object storage write flow 300 begins with client 310 transmitting a PUT OBJECT message 312 to storage system access point 320. PUT OBJECT message 312 can include a user identifier, a client Internet Protocol address, a Bucket name (the name of a directory location containing data to be accessed), an Object name (the name of an Object to be accessed), or the like. If client 310 is blocked from communicating with storage system access point 320, a 403 FORBIDDEN error can be returned in response to the PUT OBJECT message 312” and ”the storage access point system attempts to execute the second access request, and in response to successfully accessing the second data, the storage access point transmits to an external audit system a second message indicating that information corresponding to the second access request is to be recorded by the external audit system. In response to determining that the second data has been successfully accessed, but that that the information corresponding to the second access request has not been recorded by the external audit system, notify the client device that the second access request failed. Note that even though the resource could be accessed, the operation fails because it could not be successfully recorded.”).
Therefore, it would have been obvious before the effective filing date of the claimed invention for one of ordinary skill in the art to modify the system created by combination of Padmanabhan, Collinson and Benedetti to include sending, by the distributed ledger node, a second access permission verification response to the data storage entity in response to the client does not have the data access permission, wherein the second access permission verification response indicates that the client does not have the data access permission as taught by Hegde. One of ordinary skill in the art would have been motivated to do so because incorporating known authorization failure response mechanisms to ensure reliable and explicit enforcement of access control policies and to provide clear verification feedback when a client lacks required permission, which is a predictable improvement in distributed access control systems.
As per claim 15, the substance of the claimed invention is identical or substantially similar to that of claim 6. Accordingly, this claim is rejected under the same rationale.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant’s disclosure:
ZHIYUAN et al., (US 10917230) discloses managing sensitive data elements in a blockchain network.
PAN et al., (CN111522809A) discloses data processing method, system and equipment.
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 Komi N. AMEVIGBE whose telephone number is (571)272-3381. The examiner can normally be reached Monday-Friday 2pm-10pm.
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, Carl Colin can be reached at (571) 272-3862. 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.
/K.N.A./Examiner, Art Unit 2493
/CARL G COLIN/Supervisory Patent Examiner, Art Unit 2493
Prosecution Insights