Detailed Action
Applicant amended claims 19, 26 and 31 and presented claims 19-32 for reconsideration on 11/25/2025.
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 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 of this title, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 19-21, 24-28 and 31-32 are rejected under 35 U.S.C. 103(a) as being unpatentable over Thump, Pub. No.: US 2019/0068627 (“Thump”), in view of Belezko et al., Pub. No.: US 2021/0149851 (“Belezko”).
Claim 19. Thump teaches:
An information management method for service administration, the method being implemented by one or more computer servers and comprising:
establishing a connection with a database, (¶¶ 99-100, 132, a connection is established for accessing a user identity repository for retrieving information about a user/entity) wherein the database is configured to store information for different services provided to a same entity using a model, the information comprising first entity information regarding a first service provided by a first service provider and second entity information regarding a second service provided by a second service provider, wherein the information regarding the first service includes a first entity information and the information regarding the second service includes a second entity information;(¶¶ 99, 132-133, a relational/linking model is used for storing service information provided to a user; multiple services/accounts provided to a particular user having different user identifiers are linked by the user identifiers)
transmitting to the database a request to obtain information regarding an asset within associated with the same entity; (¶¶ 133-134, 352-353, wherein tracking user activity across multiple cloud applications by using user identity repository indicates that a request is transmitted to the user identity repository regarding user activity/asset tracking; note that user activity includes a user identifier, a user account, etc.: ¶119, “Activity data can include the user account or other user identifier for the user associated with the events or statistics”)
receiving from the database an indication that the asset is linked to the first entity information and the second entity information are linked as related to the asset; (¶¶ 133-134, a result from the user identity repository is an indication of linking different user information to the universal user identifier for tracking the user activity across multiple cloud applications: “A particular user's accounts with different cloud applications may be linked by associating the user identifier associated with the accounts (e.g., j doe, john. doe, etc.), with a primary (universal) user identifier or SSO mechanism as mentioned above, or using another method”)
establishing a link in the database between the first and second entity information; (¶¶ 133-134, see previous step for linking two entities)
obtaining the first entity information from the first service and the second entity information from the second service, the first entity information including a first plurality of properties and the second entity information including a second plurality of properties; (¶ 88, a log collector communicates with service providers and “can obtain log files and/or event data from the service provider, where the log files and event data describe usage of services by one or more users”; ¶ 133, entity information such as “j doe” and “johen.doe” are properties obtained from different cloud applications to be annotated/associated with universal identifiers)
storing first entity information and second entity information in the database; and (¶ 99, a user identity repository is used for associating together “the account or accounts of a particular user in different cloud applications (e.g., different user identities)”; ¶ 133, different entity information such as “j doe” and “johen.doe” are stored in the user identity repository and linked to a single entity using a universal identifier)
annotating each of the first plurality of properties and each of the second plurality of properties with one of a set of generic vocabularies representing property types within the first and second entity information, wherein a first property of the first property of the first plurality of properties is annotated with a first generic vocabulary indicating the first property is of a first property type, and a second property of the second plurality of properties is annotated with the first generic vocabulary indicating that the second property is of the first property type. (¶ 122 wherein, “ the activity data may be received in different formats that are used by different cloud applications… the process 700 includes a step 708 for normalizing the data and reformatting the data into a common format for storage in, and retrieval from, the analytics and threat intelligence repository database. Reformatting the data may include categorizing and structuring the data into the common format” suggests that properties/attributes and their associated values as in ¶¶ 225-229 are mapped and stored under common properties/attributes for representing the same data. For example, reformatting and structuring data such as “name": "Sandra Lee", " login": sandra@company.com; "name": "Mike Smith", " login" : mike@company.com; "name": "John Smith", “login'': ''john@company.com''; “user/john”; “Mary” from illustrated log formats to a relational format requires creating attributes/columns for recognized properties and storing associated values under corresponding attributes/columns as a record associated with an entity/user and further linking a particular user's accounts with different cloud applications by associating the user identifier associated with the accounts (e.g., j doe, john.doe, etc.), with a primary (universal) user identifier…” as in ¶ 133)
Thump does not specifically disclose a graph database and using a graph model and establishing an edge in the graph database between the first and second entity information; storing first entity information and second entity information in the graph database.
Belezko teaches a graph database and using a graph model for storing, detecting and establishing edges/relationships among entities for entity resolutions. (Belezko, ¶ 81, “graph transformations convert the problems in entity resolution, database relations, and natural language processing from the original environments into the new environments in which the problems can be solved with high accuracies more easily by a unified method”; ¶¶ 162-163, “the set of entities…are first input… the graph objects or graph databases are built based on entity relationships… the graph objects or graph databases are transformed based on entity relationships, e.g., by defining an equivalence relation on the graph database… retaining only one vertex per equivalence class in the partition”; ¶¶ 172-173, “Edges: common row and column relations…In the graph 900, the connections are shown having rows and columns relations indicated on the interconnections, e.g., "5r, 3c" means the connected vertices have 5 rows and 3 columns in common. This is representative of the relationship between the two vertices of the particular edge or interconnection…In this example, only the number of common rows and columns are considered”)
Both Thump and Belezko process data for linking different information related to the same entity. It would have been obvious before the effective filling date of the claimed invention to a person having ordinary skill in the art to combine the applied references for disclosing a graph database and using a graph model and establishing an edge in the graph database between the first and second entity information because doing so would increase usability of Thump by providing for storing information in an alternative data structure for linking different data records related to the same entities.
Claim 26. Thump teaches:
A computer system configured to managing information for service administration, the computer system comprising one or more processor configured to execute machine-readable instructions to cause the computer system to perform:
establishing a connection with a graph database, wherein the graph database is configured to store information for different services provided to a same entity using a graph model, the information comprising first entity information regarding a first service provided by a first service provider and second entity information regarding a second service provided by a second service provider, wherein the information regarding the first service includes a first entity information and the information regarding the second service are provided to a same includes a second entity information; (¶¶ 99-100, 132-133, a connection is established for accessing a user identity repository for retrieving information about a user/entity, a relational/linking model is used for storing service information provided to a user; multiple services/accounts provided to a particular user having different user identifiers are linked by the user identifiers)
transmitting to the database a request to obtain information regarding an asset within associated with the same entity; (¶¶ 133-134, 352-353, wherein tracking user activity across multiple cloud applications by using user identity repository indicates that a request is transmitted to the user identity repository regarding user activity/asset tracking; note that user activity includes a user identifier, a user account, etc.: ¶119, “Activity data can include the user account or other user identifier for the user associated with the events or statistics”)
receiving from the database an indication that the asset is linked to the first entity information and the second entity information are linked as related to the asset; (¶¶ 133-134, a result from the user identity repository is an indication of linking different user information to the universal user identifier for tracking the user activity across multiple cloud applications: “A particular user's accounts with different cloud applications may be linked by associating the user identifier associated with the accounts (e.g., j doe, john. doe, etc.), with a primary (universal) user identifier or SSO mechanism as mentioned above, or using another method”)
establishing a link in the database between the first and second entity information; (¶¶ 133-134, see previous step for linking two entities)
obtaining the first entity information from the first service and the second entity information from the second service, the first entity information including a first plurality of properties and the second entity information including a second plurality of properties; (¶ 88, a log collector communicates with service providers and “can obtain log files and/or event data from the service provider, where the log files and event data describe usage of services by one or more users”; ¶ 133, entity information such as “j doe” and “johen.doe” are properties obtained from different cloud applications to be annotated/associated with universal identifiers)
storing first entity information and second entity information in the database; (¶ 99, a user identity repository is used for associating together “the account or accounts of a particular user in different cloud applications (e.g., different user identities)”; ¶ 133, different entity information such as “j doe” and “johen.doe” are stored in the user identity repository and linked to a single entity using a universal identifier)
annotating each of the first plurality of properties and each of the second plurality of properties with one of a set of generic vocabularies representing property types within the first and second entity information, wherein a first property of the first property of the first plurality of properties is annotated with a first generic vocabulary indicating the first property is of a first property type, and a second property of the second plurality of properties is annotated with the first generic vocabulary indicating that the second property is of the first property type. (¶ 122 wherein, “ the activity data may be received in different formats that are used by different cloud applications… the process 700 includes a step 708 for normalizing the data and reformatting the data into a common format for storage in, and retrieval from, the analytics and threat intelligence repository database. Reformatting the data may include categorizing and structuring the data into the common format” suggests that properties/attributes and their associated values as in ¶¶ 225-229 are mapped and stored under common properties/attributes for representing the same data. For example, reformatting and structuring data such as “name": "Sandra Lee", " login": sandra@company.com; "name": "Mike Smith", " login" : mike@company.com; "name": "John Smith", “login'': ''john@company.com''; “user/john”; “Mary” from illustrated log formats to a relational format requires creating attributes/columns for recognized properties and storing associated values under corresponding attributes/columns as a record associated with an entity/user and further linking a particular user's accounts with different cloud applications by associating the user identifier associated with the accounts (e.g., j doe, john.doe, etc.), with a primary (universal) user identifier…” as in ¶ 133)
Thump does not specifically disclose a graph database and using a graph model and establishing an edge in the graph database between the first and second entity information; storing first entity information and second entity information in the graph database;
Belezko teaches a graph database and using a graph model for storing, detecting and establishing edges/relationships among entities for entity resolutions. (Belezko, ¶ 81, “graph transformations convert the problems in entity resolution, database relations, and natural language processing from the original environments into the new environments in which the problems can be solved with high accuracies more easily by a unified method”; ¶¶ 162-163, “the set of entities…are first input… the graph objects or graph databases are built based on entity relationships… the graph objects or graph databases are transformed based on entity relationships, e.g., by defining an equivalence relation on the graph database… retaining only one vertex per equivalence class in the partition”; ¶¶ 172-173, “Edges: common row and column relations…In the graph 900, the connections are shown having rows and columns relations indicated on the interconnections, e.g., "5r, 3c" means the connected vertices have 5 rows and 3 columns in common. This is representative of the relationship between the two vertices of the particular edge or interconnection…In this example, only the number of common rows and columns are considered”)
Both Thump and Belezko process data for linking different information related to the same entity. It would have been obvious before the effective filling date of the claimed invention to a person having ordinary skill in the art to combine the applied references for disclosing a graph database and using a graph model and establishing an edge in the graph database between the first and second entity information because doing so would increase usability of Thump by providing for storing information in an alternative data structure for linking different data records related to the same entities.
Thump as modified teaches:
Claim 20. The information management method of claim 19 further comprising:
generating a display request for displaying the asset in association with the first service and second service. (Thump, ¶ 51, a user account activity with respect to provided services can be displayed: “the security monitoring and control system 102 can enable tenants of a cloud services provider to view information about use of the provider's services by the user accounts of each tenant”)
Claim 27 is rejected under the same rationale.
Claim 21. The information management method of claim 19, wherein the asset comprises a user, a user group, a license, a file, a mailbox, a hardware, a computing device and/or an organization. (Thump, ¶119, a user activity data includes a user account or identifier)
Claim 28 is rejected under the same rationale.
Claim 24. The information management method of claim 19, wherein annotating the first entity information and the second entity information with the set of generic vocabularies comprises:
retrieving from the graph database the first entity information; (Thump, ¶ 133, a user identity repository is used for retrieving different user identifiers for tracking a user activity; Belezko, ¶¶ 81, 162-163)
determining the first entity information is of a first type; (Thump, ¶ 133, user identifiers jdoe, john.doe are both username type)
retrieving one or more generic vocabularies from the set of generic vocabularies based on the first type; (Thump, ¶ 133, user identifiers jdoe, john.doe are both username type to be annotated by a universal identifier)
annotating the first entity information according to the one or more generic vocabularies. (Thump, ¶ 133, a universal identifier is a common/generic vocabulary for identifying different user identifiers of a user)
Claim 31 is rejected under the same rationale.
Claim 25. The information management method of claim 19, wherein the method further comprises:
creating a common entity including a first common entity, wherein the first common entity includes the first generic vocabulary. (Thump, ¶ 133, a universal identifier is a common/generic vocabulary for identifying different user identifiers of a user)
Claim 32 is rejected under the same rationale.
Claims 22-23 and 29-30 are rejected under 35 U.S.C. 103(a) as being unpatentable over Thump and Belezko, in view of Murray et al. Patent No.: US 10,572,935 (Murray).
Claim 22. Thump as modified teaches:
The information management method of claim 1 further comprising:
retrieving from the graph database the first entity information and the second entity information; (Thump, ¶ 133, a user identity repository is used for retrieving different user identifiers for tracking a user activity; Belezko, ¶¶ 81, 162-163)
determining that the first entity information and the second entity information are both of a first type; (¶ 133, user identifiers j doe, john.doe are both username type)
in response to the determination that the first entity information and second entity information are to be linked, generate and transmit a request to the graph database to link the first entity information and the second entity information. (Thump, ¶¶ 133-134, “A particular user's accounts with different cloud applications may be linked by associating the user identifier associated with the accounts (e.g., j doe, john.doe, etc.), with a primary (universal) user identifier or SSO mechanism as mentioned above, or using another method”; Belezko, ¶¶ 81, 162-163)
Thump as modified did not teach but Murray teaches:
determining whether the first entity information and the second entity information are to be linked based on one or more preset criteria; (Murray, col. 5, ll. 3-14 and col. 6, ll. 18-30 and wherein based on a similarity threshold two entities are determined to be same)
Thump and Murray are combinable because both links two different user identifiers of the same entity. It would have been obvious before the effective filling date of the claimed invention to a person having ordinary skill in the art to combine the applied references for disclosing determining whether the first entity information and the second entity information are to be linked based on one or more preset criteria because doing so would increase usability of Thump by further utilizing a preset criteria for linking similar information related to the same entity.
Claim 29 is rejected under the same rationale.
Claim 23. The information management method of claim 19 further comprising:
retrieving from the graph database the first entity information and the second entity information; and (Murray, col. 5, ll. 3-14 and col. 6, ll. 18-30 and wherein based on a similarity threshold two retrieved entities are determined to be same; Belezko, ¶¶ 81, 162-163)
determining the first and second entity information are to be unlinked based on a set of preset criteria; and (Murray, col. 5, ll. 3-14 and col. 6, ll. 18-30 and wherein based on a similarity threshold two retrieved entities are determined to be different entities; Belezko, ¶¶ 81, 162-163)
generating and transmitting to the graph database a request to unlink the first and second entity information. (Murray, col. 5, ll. 3-14 and col. 6, ll. 18-30 and wherein based on a similarity threshold two retrieved entities are determined to be different and they are not linked; Belezko, ¶¶ 81, 162-163)
Claim 30 is rejected under the same rationale.
Response to Amendment and Arguments
In light of amendments, claim objections are withdrawn.
In light of the express abandonment of the 17/152,778 application, the double patenting rejections are withdrawn.
Applicant’s arguments with respect to the rejected claims have been considered but are not persuasive for at least the following reason.
Applicant argues: “Thump does not describe annotating the fields as name types, but rather describes linking the content of those fields (i.e., "j doe" and "john.doe") to a primary user identifier. Thump, in its entirety, does not describe any "property" or even specifically a "name type" property. Remarks, 11.
In response: Normalizing and reformatting users’ activity data such as “name": "Sandra Lee", " login": sandra@company.com; "name": "Mike Smith", " login" : mike@company.com; "name": "John Smith", “login'': ''john@company.com''; “user/john”; “Mary” received in different format from different service providers for identifying a type of action, the number of occurrences of an action, a user that performed the action, other information about accessing or operating an application, etc., as in ¶¶ 121-122, 291 requires identifying different type of properties/attributes such as name, login, etc., and mapping the identified information to equivalence properties/attributes/columns names in a common format and structure, otherwise the system would not be able map a name in the activity data in different formats to a name in a common format.
See, Merritt et al., Patent No.: US 10,467,201 B1, col. 8, ll. 30-43 for an example of normalizing and reformatting information: “In FIG. 3C, a master schema mapping for two fields of a dataset, namely, dataset_id 318 and first name 320 is shown. As illustrated in the FIG. 3C, field ids from the data sets 306, 308, and 310 may be mapped to dataset_id field 402. For instance, field id from the dataset 302, pk from dataset 308 and myid from dataset 310 may be mapped to dataset_id field 318. Similarly, fields "name", "given_nm" and "first" may be mapped to filed "firstname" 320.”
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
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 extension fee 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 Mohsen Almani whose telephone number is (571)270-7722. The examiner can normally be reached on M-F, 9 AM-5 PM, ET.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Ann J. Lo can be reached on 571-272-9767. 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 the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see https://ppair-my.uspto.gov/pair/PrivatePair. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/MOHSEN ALMANI/Primary Examiner, Art Unit 2159
Prosecution Insights