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 .
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 12/11/2025 has been entered.
Response to Arguments
Applicant’s arguments with respect to claim(s) 1 has been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
Claims 1-20 are rejected under 35 U.S.C. 103 as being unpatentable over US 20170329991 A1 to Van Dyne et al. (Van Dyne) in view of US 20210042274 A1 to Lee (Lee).
Regarding claim 1, Van Dyne teaches a method comprising: receiving, by a device, a request for user data from a user (Van Dyne [0062], e.g., a computing device may receive a request from a requestor regarding handling of data); analyzing, by the device, the request (Van Dyne [0068], e.g., the computing device may determine contextual information for the data); determining, by the device, based on the analysis, a set of policies associated with the user data, the set of policies providing jurisdictional guidelines for controlling how the user data is capable of being used (Van Dyne [0048], Data-handling requirements may be derived by the rule logic module 214 from regulations, standards (e.g., technical standards, business standards, etc.), laws); determining, by the device, based on the analysis, consent information associated with the request, the consent information corresponding to an intended use of the user data (Van Dyne [0062], e.g., the request may specify a particular action or type of action that will be performed with the data or has been performed with the data); identifying, by the device, [a data structure comprising merged] provenance tags associated with the user data (Van Dyne [0021], e.g., The contextual information 112 may include function data, authority data, control data, class data, and/or history data (as illustrated in FIG. 1). The contextual information 112 may then be associated with the data 110 through tagging or other methods), [the -data structure indicating a hierarchical representation of relative restrictiveness associated with each of the merged provenance tags, the restrictiveness being related to at least one of data access or data usage]; performing access control processing, by the device, based on the [identified data structure comprising the merged] provenance tags, the consent information and the set of policies (Van Dyne [0064], e.g., determine a response to the request based on the contextual information, and/or one or more data-handling requirements…… additionally, be based on an action or type of action being taken); determining, by the device, based on the access control processing, access rights to the user data for the user responsive to the request (Van Dyne [0065], e.g., the computing device may provide the response to the requestor); and outputting, by the device, a response to the request based on the determined access rights (Van Dyne [0065], e.g., This may include sending the response over a network, causing the response to be output via a User Interface (UI), and so on; [0022], e.g., service provider 102 may analyze the data 110, the contextual information 112, and/or one or more data-handling requirements that are applicable to the request 116 to determine (or generate) a response).
Van Dyne does not explicitly teach, but Lee teaches identifying, by the device, a data structure comprising merged provenance tags associated with the user data (Lee [0042]-[0045], e.g., the ubiquitous tag object can be…… assigned to a tagged/taggable object such as a file or unified data object to manage the tagged/taggable object…… the ubiquitous tag object may be defined by combining two or more of other ubiquitous tag objects, and may be called an aggregate ubiquitous tag object (aggregate ubiquitous tag). The user may use the aggregate ubiquitous tag object to easily assign and manage several tags at once), the -data structure indicating a hierarchical representation of relative restrictiveness associated with each of the merged provenance tags (Lee [0044], e.g., When multiple ubiquitous tag objects overlap, effective ubiquitous tag object(s) may be selected automatically according to the use context or by the user. In such case where the ubiquitous tag objects have conflicting “settings information”, the ubiquitous tag object(s) may be applied based on determined priorities using the tag order/priority information of the ubiquitous tag object(s), or based on arbitrarily determined priorities without referring to the tag order/priority information), the restrictiveness being related to at least one of data access or data usage (Lee [0043], e.g., the ubiquitous tag object may include permission/rights information regarding the access and use of the ubiquitous tag object itself and tag order/priority information between several ubiquitous tag objects. The ubiquitous tag object may also include permission/rights information regarding the access and use of the tagged/taggable object assigned with the ubiquitous tag object; [0030], e.g., tag object management unit may create the tag order/priority information regarding the tag object using the at least one of the permission/rights information regarding the tag object, the permission/rights information regarding the data item to which the tag object is applied, the security settings information related to encryption of the data item to which the tag object is applied, and the tag application scope information regarding the data item to which the tag object is applied), and performing access control processing, by the device, based on the identified data structure comprising the merged provenance tags (Lee [0088], e.g., only user devices having a specific authority may be allowed to manage the unified data object using an authority tag; [0043], e.g., ubiquitous tag object may also include permission/rights information regarding the access and use of the tagged/taggable object assigned with the ubiquitous tag object).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, to have modified the contextual data management system of Van Dyne with the ubiquitous tagging system and hierarchy of Lee with reasonable expectation of success. One of ordinary skill in the art would have been motivated to make the modification for the benefit of facilitating easier search of data (Lee [0088], e.g., the present invention allows the user to easily search for desired data by providing the data according to the tag information assigned to the unified data object rather than a folder concept of a vertical structure, and enables unified data objects to be traversed by inquiring about the unified data object on the basis of the tag information. In addition, the present invention may also provide the unified data objects on the basis of a plurality of pieces of tag information).
Regarding claim 2, most of the limitations of this claim have been noted in the rejection of claim 1. Van Dyne further teaches determining, via the access control processing, that the [merged] provenance tags and consent information are compliant with the set of policies (Van Dyne [0064], e.g., At 406, the computing device may determine a response to the request based on the contextual information, updated contextual information, and/or one or more data-handling requirements that are applicable to the request), wherein the access rights comprise functionality enabling the user to access the user data in accordance with the intended use (Van Dyne [0065], e.g., At 408, the computing device may provide the response to the requestor. This may include sending the response over a network, causing the response to be output via a User Interface (UI)).
Van Dyne does not explicitly teach, but Lee teaches merged tags (Lee [0045], e.g., the ubiquitous tag object may be defined by combining two or more of other ubiquitous tag objects, and may be called an aggregate ubiquitous tag object (aggregate ubiquitous tag). The user may use the aggregate ubiquitous tag object to easily assign and manage several tags at once).
The motivation to combine is the same as that of claim 1.
Regarding claim 3, most of the limitations of this claim have been noted in the rejection of claim 2. Van Dyne further teaches wherein the response is a “true” response indicating approval to access the user data, wherein the enabled access is based on the “true” response (Van Dyne [0065], e.g., At 408, the computing device may provide the response to the requestor, [0067], e.g., At 412, the computing device may determine that an action or type of action has been performed. As one example, the computing device may determine that an action or type of action identified in a request has been performed).
Regarding claim 4, most of the limitations of this claim have been noted in the rejection of claim 1. Van Dyne further teaches determining, via the access control processing, that the [merged] provenance tags and the consent information are non-compliant with the set of policies, wherein the access rights comprise functionality denying the request (Van Dyne [0064]-[0066], e.g., At 406, the computing device may determine a response to the request based on the contextual information…… and/or one or more data-handling requirements that are applicable to the request…… At 408, the computing device may provide the response to the requestor…… At 410, the computing device may transform the data…… to comply with one or more data-handling requirements that are applicable to a request…… In some instances, operation 410 is performed in response to receiving an instruction (e.g., requestor input, instruction from an application, etc.) to perform a transform, so that the data can be used for a particular purpose, such as an action identified in a request).
Van Dyne does not explicitly teach, but Lee teaches merged tags (Lee [0045], e.g., the ubiquitous tag object may be defined by combining two or more of other ubiquitous tag objects, and may be called an aggregate ubiquitous tag object (aggregate ubiquitous tag). The user may use the aggregate ubiquitous tag object to easily assign and manage several tags at once).
The motivation to combine is the same as that of claim 1.
Regarding claim 5, most if the limitations of this claim have been noted in the rejection of claim 1. Van Dyne further teaches identifying, from at least one data source, the user data (Van Dyne [0031], e.g., data may be received from the data source 104, retrieved from a data data store 216, and so on. As used herein, “data” may refer to any type of data including personal data); analyzing the user data, and determining, based on the analysis, metadata for the user data (Van Dyne [0034], e.g., The context generation module 208 may use the information determined above (e.g., an entity that acquired the data, how the data was acquired, a technology used, a choice mechanism, and/or a choice control) and/or rule logic stored in a rule logic data store 218 to determine (or generate) contextual information for data); and determining, based on the metadata, provenance tags for each type of the metadata (Van Dyne [0034]-[0039], e.g., The context generation module 208 may associate contextual information with data…… As illustrated, contextual information may include, for example:…… Function data 224…… Authority data 226…… Control data 228…… Class data 230…… History data 232).
Regarding claim 6, most of the limitations of this claim have been noted in the rejection of claim 5. Van Dyne does not explicitly teach, but Lee teaches aggregating the determined [provenance] tags into the data structure of merged [provenance] tags (Lee [0031], e.g., tag object management unit may create an aggregate ubiquitous tag including a plurality of tag objects based on a user's need/convenience or related/relevant usage information); and storing, in data storage, the data structure (Lee [0031], e.g., and may store and manage the aggregate ubiquitous tag in the tag object storage unit).
The motivation to combine is the same as that of claim 1.
Lee does not explicitly teach, but Van Dyne teaches the data tags being provenance tags (Van Dyne [0021], The contextual information 112 may include function data, authority data, control data, class data, and/or history data (as illustrated in FIG. 1). The contextual information 112 may then be associated with the data 110 through tagging or other methods).
Regarding claim 7, most of the limitations of this claim have been noted in the rejection of claim 6. Van Dyne further teaches, [wherein aggregation into the data structure corresponds to an event, the event comprising] a time tag that is included in the provenance tags (Van Dyne [0059], e.g., operation 306 may include adding a timestamp indicating a time that the contextual information was associated with the data).
Van Dyne does not explicitly teach, but Lee teaches wherein aggregation into the data structure corresponds to an event, the event comprising a time tag that is included in the tags (Lee [0051] e.g., According to an embodiment of the present invention, the unified data object and the ubiquitous tag object may obtain/derive a folder name or file metadata of a folder or file included in a file system as the tag information and may easily perform creation by converting files or their tag information; Note that timestamps are common metadata).
The motivation to combine is the same as that of claim 1.
Regarding claim 8, most of the limitations of this claim have been noted in the rejection of claim 1. Van Dyne further teaches wherein the intended usage indicated by the consent information comprises a set of field types (Van Dyne [0042], a request may specify various information, such as data involved, an action or type of action involved with data, entities involved in an action or type of action, and so on), wherein the field types indicate a type of user (Van Dyne [0042], e.g., a request may specify various information, such as…… entities involved in an action or type of action; [0011], e.g., entity may refer to a company, organization, individual, or another party), type of usage (Van Dyne [0042], e.g., a request may specify various information, such as…… an action or type of action involved with data) and a consent status (Van Dyne [0033], e.g., a choice mechanism may indicate that a pop-up window was presented with a check-box to select whether or not an application is allowed to collect location data from the data subject).
Regarding claim 9, most of the limitations of this claim have been noted in the rejection of claim 1. Van Dyne further teaches wherein the set of policies comprise at least one of a regulation, law, or a contractual obligation (Van Dyne [0048], e.g., Data-handling requirements may be derived by the rule logic module 214 from regulations, standards, laws, rules, internal policies, contractual obligations).
Regarding claim 10, most of the limitations of this claim have been noted in the rejection of claim 1. Van Dyne further teaches wherein the set of policies (Van Dyne [0034], e.g., the context generation module 208 may operate in cooperation with the rule logic module 214, which may access and/or evaluate rule logic) are based on at least one of an identity of the user, device type of the user, location of the user, or geopolitics of the user (Van Dyne [0036], e.g., Authority data 226 indicating a jurisdiction and/or authority that is applicable to data…… Example jurisdictions and/or authorities include a country, a federal government, a state or state government, a region, a regulatory agency), wherein the set of policies are further based on information about a publisher of the user data (Van Dyne [0037], e.g., a control on data that is set by an entity (e.g., contractual terms and conditions, etc.), a control regarding a data-handling requirement for data (e.g., a PCII delegate control Membership in a Public Collaborative Information Sharing Organization, etc.), a control regarding security or privacy of the data (e.g., a control for a security level associated with data, such as national security; a control for privacy that is specific to an entity).
Regarding claim 11, Van Dyne teaches a non-transitory computer-readable storage medium tangibly encoded with computer-executable instructions (Van Dyne [0028], e.g., The memory 202 (as well as all other memory described herein) may include one or a combination of computer-readable media. Computer-readable media may include computer storage media and/or communication media. Computer storage media includes…… computer readable instructions). The rest of the claim recites the non-transitory computer-readable storage medium of the method of claim 1, and is similarly analyzed.
Regarding claim 12, most of the limitations of this claim have been noted in the rejection of claim 11. Van Dyne further teaches determining, via the access control processing, that the [merged] provenance tags and the consent information are compliant with the set of policies (Van Dyne [0064], e.g., At 406, the computing device may determine a response to the request based on the contextual information, updated contextual information, and/or one or more data-handling requirements that are applicable to the request), wherein the access rights comprise functionality enabling the user to access the user data in accordance with the intended use (Van Dyne [0065], e.g., At 408, the computing device may provide the response to the requestor. This may include sending the response over a network, causing the response to be output via a User Interface (UI)), wherein the response is a "true" response indicating approval to access the user data, wherein the enabled access is based on the "true" response (Van Dyne [0065], e.g., At 408, the computing device may provide the response to the requestor, [0067], e.g., At 412, the computing device may determine that an action or type of action has been performed. As one example, the computing device may determine that an action or type of action identified in a request has been performed).
Van Dyne does not explicitly teach, but Lee teaches merged tags (Lee [0045], e.g., the ubiquitous tag object may be defined by combining two or more of other ubiquitous tag objects, and may be called an aggregate ubiquitous tag object (aggregate ubiquitous tag). The user may use the aggregate ubiquitous tag object to easily assign and manage several tags at once).
The motivation to combine is the same as that of claim 1.
Regarding claim 13, the claim recites the non-transitory computer-readable storage medium of the method of claim 4, and is similarly analyzed.
Regarding claim 14, most if the limitations of this claim have been noted in the rejection of claim 11. Van Dyne further teaches identifying, from at least one data source, the user data (Van Dyne [0031], e.g., data may be received from the data source 104, retrieved from a data data store 216, and so on. As used herein, “data” may refer to any type of data including personal data); analyzing the user data, and determining, based on the analysis, the metadata for the user data (Van Dyne [0034], e.g., The context generation module 208 may use the information determined above (e.g., an entity that acquired the data, how the data was acquired, a technology used, a choice mechanism, and/or a choice control) and/or rule logic stored in a rule logic data store 218 to determine (or generate) contextual information for data); determining, based on the metadata, provenance tags for each type of the metadata (Van Dyne [0034]-[0039], e.g., The context generation module 208 may associate contextual information with data…… As illustrated, contextual information may include, for example:…… Function data 224…… Authority data 226…… Control data 228…… Class data 230…… History data 232); [aggregating the determined provenance tags into the data structure of merged provenance tags; and storing, in data storage, the data structure].
Van Dyne does not explicitly teach, but Lee teaches aggregating the determined [provenance] tags into the data structure of merged [provenance] tags (Lee [0031], e.g., tag object management unit may create an aggregate ubiquitous tag including a plurality of tag objects based on a user's need/convenience or related/relevant usage information); and storing, in data storage, the data structure (Lee [0031], e.g., and may store and manage the aggregate ubiquitous tag in the tag object storage unit).
The motivation to combine is the same as that of claim 1.
Lee does not explicitly teach, but Van Dyne teaches the data tags being provenance tags (Van Dyne [0021], The contextual information 112 may include function data, authority data, control data, class data, and/or history data (as illustrated in FIG. 1). The contextual information 112 may then be associated with the data 110 through tagging or other methods).
Regarding claim 15, the claim recites the non-transitory computer-readable storage medium of the method of claim 8, and is similarly analyzed.
Regarding claim 16, Van Dyne teaches a device comprising: a processor (Van Dyne [0027], e.g., The one or more computing devices may be equipped with one or more processors 202). The rest of the claim recites a device of the method of claim 1, and is similarly analyzed.
Regarding claim 17, the claim recites a device of the non-transitory computer-readable storage medium of claim 12, and is similarly analyzed.
Regarding claim 18, the claim recites a device of the method of claim 4, and is similarly analyzed.
Regarding claim 19, the claim recites a device of the non-transitory computer-readable storage medium of claim 14, and is similarly analyzed.
Regarding claim 20, the claim recites a device of the method of claim 8, and is similarly analyzed.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
US 11,194,764 B1 to Adhikari et al. discloses Each effective tag policy 335A-D may be a combination of each of the tag policies along the path of nodes from the root node of the org 305 to the leaf node of a particular account. The combination may be a concatenation of multiple tag policies, a blending of multiple tag policies, an intersection of tag compliance rules of multiple tag policies, or some other combination of tag policies. The effective tag policy 335A-D for an account 325A-D describes the constraints that are applicable to that particular account. In the generation of the effective tag policies, the tag policy manager may effectively perform denormalization so that each account has a single record (the effective tag policy for that account) that identifies the tag compliance rules for that account. As a result, when a request is received to determine whether a resource and/or tag complies with the tag policies for an account, a single lookup may be performed to determine the entire set of tag compliance rules that should be met for the resource and/or tag.
Contact Information
Any inquiry concerning this communication or earlier communications from the examiner should be directed to LAWRENCE TRUONG whose telephone number is (571)272-6973. The examiner can normally be reached Monday - Friday, 8:00 am - 4 pm ET.
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, Ali Shayanfar can be reached on (571) 270-1050. 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.
/LAWRENCE TRUONG/Examiner, Art Unit 2434 /ALI SHAYANFAR/Supervisory Patent Examiner, Art Unit 2434