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 .
Status of Claims
Claims 1-20 are pending in this application.
Claim Rejections - 35 USC § 102
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
Claim(s) 1-2,6-8,11-12,15,18-19 is/are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Petri et al(US 9,705,730).
Claim 1: Petri disclose grant an access request for accessed data, the accessed data governed by an access policy and generate a hash tree for the accessed data in (fig.1; col.1,lines 48-59: generating a first Merkle tree for an object, examining an input data stream and generating a second Merkle tree for the object using the input data stream. Note that new Merkle tree is regenerated based on the data that the system accessed and data was previously granted to the system). Petri discloses store the hash tree in conjunction with the access policy and relate the access policy to uploaded data, based on the hash tree in (col.9,lines 5-31: System locates a Merkle tree of a previously stored object on a deduplicating block store Merkle. The Merkle tree comprise a hash table representation of blocks of data stored object. It compares an object at a source location to a Merkle tree representation of a previously stored version of the object on a deduplicating block store. This comparison allows for transmission of only changed blocks across the network for storage in the block store).
Claim 2: Petri disclose intercept the access request; duplicate the accessed data to obtain an accessed data copy; and generate the hash tree using the accessed data copy in (col.1,l;ines 48-59;col.5,lines 38-59).
Claim 6: Petri disclose generate the hash tree as a binary hash tree in (col.7,lines 24-34).
Claim 7: Petri disclose generate the hash tree as a Merkle tree in (col.3,lines 25-56).
Claim 8: Petri disclose store the hash tree using a graph database; and link the access policy in a policy database to a root node of the hash tree in the graph database in (col.3,lines 25-56).
Claim 11: Petri disclose grant an access request for accessed data, the accessed data governed by an access policy and generate a hash tree for the accessed data in (fig.1; col.1,lines 48-59: generating a first Merkle tree for an object, examining an input data stream and generating a second Merkle tree for the object using the input data stream. Note that new Merkle tree is regenerated based on the data that the system accessed and data was previously granted to the system). Petri discloses store the hash tree in conjunction with the access policy and relate the access policy to uploaded data, based on the hash tree in (col.9,lines 5-31: System locates a Merkle tree of a previously stored object on a deduplicating block store Merkle. The Merkle tree comprise a hash table representation of blocks of data stored object. It compares an object at a source location to a Merkle tree representation of a previously stored version of the object on a deduplicating block store. This comparison allows for transmission of only changed blocks across the network for storage in the block store).
Claim 12: Petri disclose intercept the access request; duplicate the accessed data to obtain an accessed data copy; and generate the hash tree using the accessed data copy in (col.1,l;ines 48-59;col.5,lines 38-59).
Claim 15: Petri disclose store the hash tree using a graph database; and link the access policy in a policy database to a root node of the hash tree in the graph database in (col.3,lines 25-56).
Claim 18: Petri disclose at least one memory including instructions and at least one processor that is operatively coupled to the at least one memory in (col.11,lines 1-21). Petri discloses grant an access request for accessed data, the accessed data governed by an access policy and generate a hash tree for the accessed data in (fig.1; col.1,lines 48-59: generating a first Merkle tree for an object, examining an input data stream and generating a second Merkle tree for the object using the input data stream. Note that new Merkle tree is regenerated based on the data that the system accessed and data was previously granted to the system). Petri discloses store the hash tree in conjunction with the access policy and relate the access policy to uploaded data, based on the hash tree in (col.9,lines 5-31: System locates a Merkle tree of a previously stored object on a deduplicating block store Merkle. The Merkle tree comprise a hash table representation of blocks of data stored object. It compares an object at a source location to a Merkle tree representation of a previously stored version of the object on a deduplicating block store. This comparison allows for transmission of only changed blocks across the network for storage in the block store).
Claim 19: Petri disclose store the hash tree using a graph database; and link the access policy in a policy database to a root node of the hash tree in the graph database in (col.3,lines 25-56).
Allowable Subject Matter
Claims 3-5,9-10,13-14,16-17,20 objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims.
Response to Applicant’s Arguments
Applicant argues that Petri fails to discuss or disclose any “access policy”, for example, no mention of any access control, permissions, or security enforcement are discussed in Petri. Therefore, Petri cannot disclose at least store the hash tree in conjunction with the access policy; and relate the access policy to uploaded data, based on the hash tree. Examiner respectfully disagrees. The cited reference specifically discloses an access policy through its EXIST call on a Merkle block returns ‘true’, then the whole tree relative to any Merkle block as root is considered to exist. Thus, a block store associated with a Merkle node cannot be put into the deduplicating blocks store before all of the blocks associated with children Merkle nodes are placed into the deduplicating block store which is disclosed in (col.6,lines 34-47;col.3,lines 5-24). EXIST mechanism determines whether data can be retrieved, transmitted or reconstructed which constitutes a rule governing access to data. Selective transmission is disclosed in (col.9,lines 5-15) and rule-based filtering of Merkle nodes is disclosed in (fig.2-4). Accordingly, these operations or mechanism collectively govern data access control, transmission based on predefined conditions. Under BRI, this constitutes an access policy. Further, the access-determining policies are explicitly applied and derived from the hash tree, thereby relating the policy to uploaded data as claimed.
Conclusion
THIS ACTION IS MADE FINAL. 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.
USPTO Contact Information
Any inquiry concerning this communication or earlier communications from the examiner should be directed to HOSUK SONG whose telephone number is (571)272-3857. The examiner can normally be reached Mon-Fri: 7:30AM-5:00PM.
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, Amir Mehrmanesh can be reached 571-270-3351. 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.
/HOSUK SONG/ Primary Examiner, Art Unit 2435
Prosecution Insights