DETAILED ACTION
This action is responsive to the following communications: Original Application filed on December 6, 2022, and Response to file corrected Papers, filed on February 10, 20231. All references to this application refer to the U.S. Patent Application Publication No. 2023/0161950 A1.
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Claims 1-10 are pending in this case. Claim 1 is the independent claim. Claims 1-10 are rejected.
Priority
The present application is a CONTINUATION-IN-PART of U.S. Patent Application No. 17/146,131 (now U.S. Patent No. 11,537,684), filed on January 11, 2021. Additionally, this application claims the benefit of U.S. Provisional Patent Application No. 62/959,507, filed on January 10, 2020.
Accordingly, priority is determined on a claim by claim basis.
Drawings
The replacement drawings were received on February 10, 2023. These drawings are acceptable.
Specification
The patent abstract is objected to for the following informality:
The word “imported” is missing from the sentence “The one or more defined data entities are into one or more guides.” This should recite “The one or more defined data entities are imported into one or more guides.”
Appropriate correction is required.
The disclosure is objected to because of the following informalities:
In paragraph 0035, last sentence recites “…U.S. Published Patent Appl. S.N. 2021/0216600.” This should recite “…U.S. Published Patent Appl. No. 2021/0216600.”
In paragraph 0077, the reference element 142 from Fig. 4 is missing (Role Access Filtering). It should be described here.
Appropriate corrections are required.
Claim Objections
Claims 1, 5, 8, and 9 are objected to because of the following informalities:
In each of the claims, the transition phrase “including” should be amended to recite “further including.”
Appropriate corrections are required.
Examiner’s Note
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.
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.
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. Applicants are 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-10 are rejected under 35 U.S.C. 103 as being unpatentable over U.S. Patent Application Publication No. 2015/0046791 A1, filed by Isaacson on January 6, 2014, and published on February 12, 2015 (hereinafter Isaacson), in view of U.S. Patent Application Publication No. 2010/0332973 A1, filed by Kloiber et al., on August 27, 2010, and published on December 30, 2010 (hereinafter Kloiber).
With respect to independent claim 1, Isaacson discloses, in a computing system environment, a method for data management for automated document creation, comprising:
Defining one or more data entities; Isaacson discloses defining one or more data entities (see Isaacson, Fig. 1; see also, Isaacson, paragraphs 0055 [describing the use of an ontology as a data model defined by object types and property types; for example a data object may represent a person having associated properties, attributes, or relationships] and 0056 [further describing how different types of data objects have respective different property types; a person might have eye color, while event might have date, etc.])
Associating the one or more data entities with unique identifiers in storage; Isaacson discloses that every data object is associated with a unique identifier that uniquely identifies the data object within the data store (see Isaacson, paragraph 0055, described supra).
Defining at least one relationship between the one or more defined data entities; Isaacson discloses defining at least one relationship between data objects (see Isaacson, paragraphs 0040 [relationships between persons are defined and rendered in the interface of Figs. 4A-C; for example person objects may be related to other data objects (people) such as associates, acquaintances, family members, etc.], 0041 [data objects of different types can also be related (e.g., person owning a car)], and 0043 [properties of data objects, including relationships, can be inspected (viewing details, attributes, or properties of the relationship]).
Importing the one or more defined data entities into one or more guides; Isaacson discloses importing data objects into reports (e.g., guides) (see Isaacson, Figs. 3E and 4A-C; see also, Isaacson, paragraphs 0022 [system generates reports from templates and forms and other structured data], and 0071 [snippets may be imported into bodies of reports]; see also, Isaacson, paragraphs 0040-0041, described supra).
Isaacson fails to expressly disclose providing filtered views of the one or more guides according to the one or more defined relationships.
However, Kloiber teaches using entity or role based access rights systems to prevent unauthorized users from viewing reports or filed (see Kloiber, paragraph 0034 [defining access rights for documents or portions of documents], 0039 [defining the control component for managing user access to superactive documents, such as limiting users based on rules, resource restrictions, etc.], 0101 [user access rights are controlled], 0121 [objects or content visibility is based on user identity, tile, or role; can be extended to groups, authentication, or other factors], 0158-0159 [a set of user access rights determines read, edit, delete permissions of a user with respect to the document], 0173 [user access rights govern ability for users to read, edit, approve, or modify documents], and 0186 [output queue uses access rules to determine which users have (or do not have) access to the document],
Accordingly, it would have been obvious to one of ordinary skill in the art, having the teachings of Isaacson and Kloiber before him before the effective filing date of the claimed invention, to modify the method of Isaacson to incorporate filtering reports based on the entity relationships as taught by Kloiber. One would have been motivated to make such a combination because this provides customized control over creation, modification, distribution, and execution of documents, as taught by Kloiber (see Kloiber, paragraph 0014 [“Consequently, a need exists for a superactive document, utilizable in a computer-implemented processes such as user interaction, printing, storage, communication with other entities, and submission to enterprise processes such as document creation, forms utilization, order fulfillment, customer service handling, accounting, marketing, personnel management, and a myriad of other enterprise- and organization-specific tasks and activities.”]).
With respect to dependent claim 2, Isaacson, as modified by Kloiber, teaches the method of claim 1, as described above.
Isaacson further teaches the method [further] including defining a hierarchy for the at least one defined relationship.
Isaacson further teaches defining relationships hierarchically (see Isaacson, paragraphs 0040, 0041, and 0043, described supra, claim 1).
With respect to dependent claim 3, Isaacson, as modified by Kloiber, teaches the method of claim 1, as described above.
Isaacson further teaches the method wherein supported data types for the one or more defined data entities are selected from the group consisting of text, alphanumerical, currency, date, time, datetime, Boolean, globally unique identifier, entity object with inheritance and multiple sub-properties, function data with dynamic computation, binary arrays of bytes, and mapped data.
Isaacson further teaches supported data types include at least text, alphanumerical, currency, date, time, entity objects with inheritance and sub-properties, etc. (see Isaacson, paragraphs 0057 [ontology includes tuples such as “event:payment, currency:amount, date:payment”] and 0058 [ontology support multiplicity, such as a person having multiple addresses or phone numbers]; see also, Isaacson, paragraphs 0040, 0041, 0043, 0055, and 0056, described supra, claim 1).
With respect to dependent claim 4, Isaacson, as modified by Kloiber, teaches the method of claim 3, as described above.
Isaacson further teaches the method wherein the defining one or more data entities comprises selecting variables from the group consisting of unique system names, entities from whom to inherit properties or assets, and owned properties.
Isaacson further teaches defining data entities by selecting variables including at least unique system names, owned properties, inheritable entities (see Isaacson, paragraphs 0040, 0041, 0043, 0055, and 0056, described supra, claim 1; see also, Isaacson, paragraphs 0057-0058, described supra, claim 3).
With respect to dependent claim 5, Isaacson, as modified by Kloiber, teaches the method of claim 1, as described above.
Isaacson further teaches the method [further] including defining one or more entity instances by selecting variables from the group consisting of a storage-generated globally unique instance identifier, an entity type name, a definition for authorized access to the defined entity instance, and a defined property value for the entity.
Isaacson further teaches defining entity instances by selecting variables including GUIDs, entity types, and defined property values (see Isaacson, paragraphs 0040, 0041, 0043, 0055, and 0056, described supra, claim 1; see also, Isaacson, paragraphs 0057-0058, described supra, claim 3).
With respect to dependent claim 6, Isaacson, as modified by Kloiber, teaches the method of claim 5, as described above.
Isaacson further teaches the method wherein the defined property value is selected from one or more of first name, date of birth, and address.
Isaacson further teaches the defined property value selected from at least first name and address (see Isaacson, paragraph 0058, described supra, claim 3).
With respect to dependent claim 7, Isaacson, as modified by Kloiber, teaches the method of claim 1, as described above.
Isaacson further teaches the method wherein a structure of the one or more guides is defined by selecting variables from the group consisting of a unique system name, a title, a description of the document, a model defining inherited or owned properties, and a list of principals assigned a specific role.
Isaacson further teaches the document structure is defined by selecting variables including at least unique system name, title, and document description (see Isaacson, paragraphs 0055-0056, described supra, claim 1).
With respect to dependent claim 8, Isaacson, as modified by Kloiber, teaches the method of claim 7, as described above.
Isaacson and Kloiber further teach the method [further] including defining one or more guide instances by selecting variables from the group consisting of a storage-generated globally unique guide identifier, a guide name, a definition for authorized access to the defined guide instance, and a definition for authorized access to the principals assigned a specific role.
Isaacson further teaches defining report (e.g., guide) instances by selecting variables including at least GUID and report name (see Isaacson, paragraphs 0055-0056, described supra, claim 1).
Additionally or alternatively, Kloiber further teaches defining document instances by selected variables including access rules/definitions and user roles (see Kloiber, paragraphs 0034, 0039, 0101, 0121, 0158-0159, 0173, and 0186, described supra, claim 1).
With respect to dependent claim 9, Isaacson, as modified by Kloiber, teaches the method of claim 1, as described above.
Isaacson further teaches the method [further] including defining at least one additional relationship between the one or more defined data entities.
Isaacson further teaches that any data object can have multiple (additional) relationships with other data objects (persons, objects, etc.) (see Isaacson, Figs. 4A-C; see also, Isaacson, paragraphs 0040, 0041, and 0043, described supra, claim 1).
With respect to dependent claim 10, Isaacson, as modified by Kloiber, teaches the method of claim 3, as described above.
Kloiber further teaches the method wherein the providing filtered views of the one or more guides according to the one or more defined relationships comprises selectively restricting or permitting access to one or more of the one or more guides during an engagement timeline.
Kloiber further teaches providing the filtered views of the documents by selective restrictions or permissions to the documents during an engagement timeline (see Kloiber, paragraphs 0034, 0039, 0101, 0121, 0158-0159, 0173, and 0186, described supra, claim 1).
Conclusion
The prior art made of record and not relied upon is considered pertinent to Applicants’ disclosure.
See PTO-892
It is noted that any citation to specific pages, columns, figures, or lines in the prior art references any interpretation of the references should not be considered to be limiting in any way. A reference is relevant for all it contains and may be relied upon for all that it would have reasonably suggested to one having ordinary skill in the art. In re Heck, 699 F.2d 1331-33, 216 USPQ 1038-39 (Fed. Cir. 1983) (quoting In re Lemelson, 397 F.2d 1006, 1009, 158 USPQ 275, 277 (CCPA 1968)).
Any inquiry concerning this communication or earlier communications from the Examiner should be directed to ERIC J. BYCER whose telephone number is (571) 270-3741. The Examiner can normally be reached Monday - Thursday 9am-6pm, and alternate Fridays 9am-5pm.
Examiner interviews are available via a variety of formats. See MPEP § 713.01. To schedule an interview, Applicants are encouraged to use the USPTO Automated Interview Request (AIR) Form at https://www.uspto.gov/InterviewPractice.
If attempts to reach the Examiner by telephone are unsuccessful, the Examiner’s supervisor, KIEU D. VU can be reached on (571) 272-4057. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from Patent Center. Status information for published applications may be obtained from Patent Center. Status information for unpublished applications is available through Patent Center to authorized users only. Should you have questions about access to the USPTO patent electronic filing system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free).
/ERIC J. BYCER/
Primary Examiner
Art Unit 2141
1 Note: While the replacement drawings appear in the published application, the amendment to the Specification changing “step 134” to “step 135” (which should appear at the end of printed publication paragraph 0076) is not present. Should the application mature into a patent, Applicants are recommended to review the printed patent to ensure that the correction properly appears.