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 April 29, 2026 has been entered.
Claim Objections
Applicant is advised that should claim 1 be found allowable, claim 19 will be objected to under 37 CFR 1.75 as being a substantial duplicate thereof. When two claims in an application are duplicates or else are so close in content that they both cover the same thing, despite a slight difference in wording, it is proper after allowing one claim to object to the other as being a substantial duplicate of the allowed claim. See MPEP § 608.01(m). Claim 19 compared with claim 1 results in the following:
19. (Currently Amended) A system comprising a computer program product including a memory and a processor for executing instructions stored in the memory, the instructions causing a computer to perform:assigning, by an entity identifier (EID) assignment engine, a first entity identifier to a first data item in a multitenant EID lineage-persistent relational database management system (RDBMS);maintaining, by a legacy EID retention engine comprising a legacy EID survivorship subengine and a lineage EID promotion subengine, the first EID during survivorship and lineage EID promotion processes in [[a]]the multitenant EID lineage-persistent RDBMS ;changing, by a data item update engine, data items, including merging the first data item in the multitenant EID lineage-persistent RDBMS with a second data item in the multitenant EID lineage-persistent RDBMS that has a second EID, which triggers survivorship and lineage EID promotion, wherein when the first data item is merged with the second data item in the multitenant EID lineage-persistent RDBMS, the first EID is promoted to primary EID of the merged data item by the lineage EID promotion subengine, and wherein when the first data item is merged with the second data item in the multitenant EID lineage-persistent RDBMS, the second EID is retained as a second legacy EID of a second data item portion of the merged data item by the legacy EID retention engine, thereby facilitating cross-tenant durability within the multitenant EID lineage-persistent RDBMS.
Response to Arguments
Applicant’s arguments with respect to 35 USC 101 have been fully considered and are persuasive. The rejection of the claims under 35 USC 101 has been withdrawn.
Swift et al. (U.S. Patent No. 5,768,519, hereinafter referred to as “Swift”).
Regarding claim 1, Swift discloses a system comprising: one or more processors; and memory storing instructions that, when executed by the one or more processors, cause the system to perform: (“The present invention generally relates to computer object maintenance facilities, and more particularly to methods for maintaining previously established relationships between computer resources when maintenance objects are reconfigured in a computer network.”)(e.g., figures 1 and 6 and col 1 lines 7-11)
assigning, by an entity identifier (EID) assignment engine, a first EID to a first data item in a multitenant EID lineage-persistent relational database management system (RDBMS); (“The File Server 6 accesses a directory service of objects database 7 ("database 7") which is preferably stored on a hard drive accessed by the File Server 6, in order to authenticate user and service logon credentials and provide security contexts after authenticating the logon credentials. The database 7 stores known account information enabling the File Server 6 (the Domain #1 controller) to authenticate user and service logon names and associated passwords and then build security contexts for the authenticated logged on users and services. Thus, the database 7 is accessed by the File Server 6 (in its role as the Domain #1 controller) in order to authenticate user and service account credentials and to create a security context when a user or service, such as User 8, 10, or 12, attempts to log onto the Domain #1.” “Domain #2, enclosed by the box 4, includes a File Server 18. The File Server 18, which also performs the functions described above associated with a domain controller, also includes a directory service of objects database 19 ("database 19"). Database 19 contains the same type of account security information described above for the database 7. The information in the database 19 facilitates authentication of user and service logons by the Domain #2 controller (File Server 18) and creating security contexts for authenticated logged on users and services associated with Domain #2. Domain #2 comprises Users 20, 22, 24, 26, 28, 30, 32, 34, and 36. Domain #2 also comprises a Print Server 38 and an SQL Server 40. Domain #2 also includes a Group 41 comprising the Users 30, 32 and 34. The Group 41 has the name "Instructors."”)(e.g., figures 2-4 and col 5 lines 31-44 and 53-67)
maintaining, in the multitenant EID lineage-persistent RDBMS by a legacy EID retention engine comprising a legacy EID survivorship subengine and a lineage EID promotion subengine, the first EID during survivorship and lineage EID promotion processes; (“if an account is transferred to a new domain during a domain merge operation, then the former SID for the account is appended to the Group List 56. The transferred account is associated with a new Domain ID corresponding to the new domain and a new relative ID is inserted within the Current Relative ID field 54 for the transferred account. Each time the account is transferred to a new domain (necessitating assigning a new SID to the account), the former SID is added to the Group List 56 by a merging tool. The former SIDs are present in security contexts accompanying user or service requests and therefore enable users and services to maintain access to protected network resources when the ACLs of the protected network resources have not been updated to include the new SIDs assigned to transferred accounts during a domain merge procedure.” )(e.g., figures 2-4 and col 7 lines 36-51)
changing, by a data item update engine, data items, including merging the first data item in the multitenant EID lineage-persistent RDBMS with a second data item in the multitenant EID lineage-persistent RDBMS that has a second EID, which triggers survivorship and lineage EID promotion, wherein when the first data item is merged with the second data item in the multitenant EID lineage-persistent RDBMS, the first EID is promoted to primary EID of the merged data item by the lineage EID promotion subengine, and wherein when the first data item is merged with the second data item in the multitenant EID lineage-persistent RDBMS, the second EID is retained as a second legacy EID of a second data item portion of the merged data item by the legacy EID retention engine, thereby facilitating cross-tenant durability within the multitenant EID lineage-persistent RDBMS. (“Furthermore during step 106, the merging tool builds a temporary merging table containing entries corresponding to the merging Domain #1 accounts. Each entry comprises a merged account name. It is noted that in the event that a name for a merged account is changed, the new account name is placed in the temporary merging table. In addition, each entry for a merged account includes an old relative ID corresponding to the account in Domain #1 and a new relative ID corresponding to the account in Domain #2. For example, when an account is created in Domain #2 for the User 8 during step 106, the merging tool creates an entry in the temporary merging table having a name "Bob", an old relative ID of "1", and a new relative ID "13." Though the temporary merging table is not necessary for carrying out the present invention, it reduces the searching performed by the merging tool in order to locate relative IDs corresponding to merged account names during later steps of the domain merge process.” “As a result, when domains are merged and an account is assigned a new SID, access to protected resources using ACLs based upon the old SID will be lost. Therefore, adding a previously used SID to the account security data structure and creating a context based upon both the new and previously used SIDs for an account ensures that access to any protected resource is maintained (via the stored previous SID) even after the domain with which the account was previously associated is merged into another domain.”)(e.g., e.g., figures 2-4 and 8 and col 11 lines 14-30 and 48-57).
Regarding claim 2, Swift discloses the system of claim 1. Swift further discloses comprising a new dataset onboarding engine that receives a new dataset including the first data item that is assigned the first EID by the EID assignment engine. (“It is noted that a context may include SIDs from more than a single merged domain. A non-local controller, upon receiving a context including SIDs from multiple merged domains, may determine that the authority of the issuing domain controller (e.g., Domain #2 controller) to issue one or more SIDs within the context is not confirmed/supported by the presence of a validating certificate within the context. When the context includes other, confirmed SIDs (by virtue of other valid certificates in the context), it is contemplated that a variety of possible responses can be formulated by a domain controller. The receiving domain controller may issue a general failure to the issuing domain controller and not forward the request or SIDs to the appropriate server even when valid (certificate confirmed) SIDs are included in the request from another domain. Alternatively, the domain controller may forward to the server only the SIDs corresponding to confirming certificates contained within the received context and discard any SIDs for which a confirming certificate could not be identified.”)(e.g., col 16 lines 47-65).
Regarding claim 3, Swift discloses the system of claim 1. Swift further discloses comprising an object registration engine that registers the first data item in association with a source of the first data item. (“In an operating system utilizing an Access Control List (ACL) based resource protection scheme (such as the WINDOWS.TM. NT operating system), it is not likely that all the ACLs will be updated immediately after a domain merge. As a result, when domains are merged and an account is assigned a new SID, access to protected resources using ACLs based upon the old SID will be lost. Therefore, adding a previously used SID to the account security data structure and creating a context based upon both the new and previously used SIDs for an account ensures that access to any protected resource is maintained (via the stored previous SID) even after the domain with which the account was previously associated is merged into another domain. In order to facilitate continued access by users and services to network resources that do not have updated ACLs, during step 106 the merging tool copies the Domain #1 ID and the relative ID, which in combination form the former SID, for each merged individual account into a corresponding new individual account in Domain #2 (the target domain). In the preferred embodiment of the present invention, the former account SID is stored in the Group List 56 of a new individual account in Domain #2 corresponding to the merged account. Thus, for example, during step 106 the merging tool copies the SID 1:1, previously assigned to the User 8 ("Bob"), to the Group List 56 within the new account in Domain #2 for the User 8 having a new SID 2:13. It is noted that while in the preferred embodiment of the present invention the old SID is placed in the Group List 56 of the corresponding new individual account in Domain #2, in alternative embodiments of the invention the old SID will be placed in some equally acceptable alternative location referenced by network security systems in order to determine other security identifications with which an account has been, or is currently, associated.”)(e.g., figures 2-4 and col 11 line 45 – col 12 line 11).
Regarding claim 4, Swift discloses the system of claim 1. Swift further discloses wherein the first EID references a real-world entity. (“an Account Name field 50 specifies a name corresponding to an account that uniquely identifies the account within a domain with which the account is associated. The domain with which an account is associated is identified by a Current Domain ID 52. An account's Current Domain ID 52 distinguishes the account from other accounts associated with different domains within a same network having a same account name or relative identification (stored in field 54 described below). For example, in FIG. 1, a logon request originating from User 12 ("AL") is distinguished from a logon request from User 36 (also having the name "AL") by the association of the User 12 with a unique Domain #1 identification which is distinguished from the Domain #2 identification. Likewise, the Current Domain ID 52, in combination with a relative identification for a specific account, uniquely identifies the account within a network wherein other accounts contain a same relative account identification.”)(e.g., figures 1 and 6 and col 6 lines 45-63)
Regarding claim 5, Swift discloses the system of claim 1. Swift further discloses wherein when the first data item is merged with the second data item, the first EID is retained as a first legacy EID of a first data item portion of the merged data item by the legacy EID survivorship subengine. (“The group SIDs that were present within the Group List 56 before the account was merged into a new domain are retained in the Group List 56.” “Therefore, adding a previously used SID to the account security data structure and creating a context based upon both the new and previously used SIDs for an account ensures that access to any protected resource is maintained (via the stored previous SID) even after the domain with which the account was previously associated is merged into another domain.”)(e.g., figures 2-4 and col 7 lines 33-35 and col 11 lines 51-57)
Regarding claim 8, Swift discloses the system of claim 1. Swift further discloses wherein merging the first data item with the second data item produces a third data item with a third EID. (“Therefore, when an account is merged into a new domain, new group SIDs are added to the Group List 56 which correspond to the new SIDs for the transferred group accounts. The group SIDs that were present within the Group List 56 before the account was merged into a new domain are retained in the Group List 56.” “Furthermore during step 102, as shown in FIG. 5, the merging tool selects new account names in order to eliminate the account name matches. The merging tool initially attempts to eliminate an account name match by adding the extension ".sub.-- 1" to the duplicated account name from the source domain (Domain #1) in order to generate a new, possibly non-conflicting account name.”)(e.g., col 7 lines 30-35 and col 9 line 66 – col 10 line 5)
Regarding claim 9, Swift discloses the system of claim 1. Swift further discloses wherein the first EID is a first tenant EID, wherein data in the first data item is included in a third data item with a third EID, wherein the third EID is a second tenant EID, wherein the first tenant EID and the second tenant EID are EIDs of different tenants, and wherein a fourth EID is associated with the first tenant EID and the second tenant EID. (“The certificates embody a transitive property enabling the chaining of certificates in order to establish an authority for a particular domain controller to issue contexts including SIDs identifying another domain. For example, if Domain #1 transfers a certificate to Domain #2 during a merger of Domain #1 into Domain #2, and Domain #2 transfers a certificate to Domain #3 during a merger of Domain #2 into Domain #3, then Domain #3 will be authorized to issue SIDs including the domain ID for Domain #1. As a consequence, trust relationships can be effectively maintained even when a large number of mergers are performed upon a group of accounts in a relatively short period of time.” “when a source domain is absorbed into a target domain during a domain merge operation, trust relationships established by the source domain with the other domains are passed to the target domain when the target domain controller stores the old account SIDs in the Group List field 56 for each transferred account, and a corresponding certificate is issued. The target domain controller thereafter issues security contexts including the old account SIDs.”)(e.g., figures 1-4 and 6 and col 14 line 66 – col 15 line 10 and col 8 lines 1-8).
Regarding claim 10, Swift discloses a method comprising: (“a method for merging a source domain into a target domain in a network. More particularly, the method for merging domains in accordance with the present invention”)(e.g., col 3 lines 62-64)
assigning, by an entity identifier (EID) assignment engine, a first entity identifier to a first data item in a multitenant EID lineage-persistent relational database management system (RDBMS); (“The File Server 6 accesses a directory service of objects database 7 ("database 7") which is preferably stored on a hard drive accessed by the File Server 6, in order to authenticate user and service logon credentials and provide security contexts after authenticating the logon credentials. The database 7 stores known account information enabling the File Server 6 (the Domain #1 controller) to authenticate user and service logon names and associated passwords and then build security contexts for the authenticated logged on users and services. Thus, the database 7 is accessed by the File Server 6 (in its role as the Domain #1 controller) in order to authenticate user and service account credentials and to create a security context when a user or service, such as User 8, 10, or 12, attempts to log onto the Domain #1.” “Domain #2, enclosed by the box 4, includes a File Server 18. The File Server 18, which also performs the functions described above associated with a domain controller, also includes a directory service of objects database 19 ("database 19"). Database 19 contains the same type of account security information described above for the database 7. The information in the database 19 facilitates authentication of user and service logons by the Domain #2 controller (File Server 18) and creating security contexts for authenticated logged on users and services associated with Domain #2. Domain #2 comprises Users 20, 22, 24, 26, 28, 30, 32, 34, and 36. Domain #2 also comprises a Print Server 38 and an SQL Server 40. Domain #2 also includes a Group 41 comprising the Users 30, 32 and 34. The Group 41 has the name "Instructors."”)(e.g., figures 2-4 and col 5 lines 31-44 and 53-67)
maintaining, by a legacy EID retention engine comprising a legacy EID survivorship subengine and a lineage EID promotion subengine, the first EID during survivorship and lineage EID promotion processes in the multitenant EID lineage-persistent RDBMS by a legacy EID retention engine comprising a legacy EID survivorship subengine and a lineage EID promotion subengine, the first EID during survivorship and lineage EID promotion processes; (“if an account is transferred to a new domain during a domain merge operation, then the former SID for the account is appended to the Group List 56. The transferred account is associated with a new Domain ID corresponding to the new domain and a new relative ID is inserted within the Current Relative ID field 54 for the transferred account. Each time the account is transferred to a new domain (necessitating assigning a new SID to the account), the former SID is added to the Group List 56 by a merging tool. The former SIDs are present in security contexts accompanying user or service requests and therefore enable users and services to maintain access to protected network resources when the ACLs of the protected network resources have not been updated to include the new SIDs assigned to transferred accounts during a domain merge procedure.” )(e.g., figures 2-4 and col 7 lines 36-51)
changing, by a data item update engine, data items, including merging the first data item in the multitenant EID lineage-persistent RDBMS with a second data item in the multitenant EID lineage-persistent RDBMS that has a second EID, which triggers survivorship and lineage EID promotion, wherein when the first data item is merged with the second data item in the multitenant EID lineage-persistent RDBMS, the first EID is promoted to primary EID of the merged data item by the lineage EID promotion subengine, and wherein when the first data item is merged with the second data item in the multitenant EID lineage-persistent RDBMS, the second EID is retained as a second legacy EID of a second data item portion of the merged data item by the legacy EID retention engine, thereby facilitating cross-tenant durability within the multitenant EID lineage-persistent RDBMS. (“Furthermore during step 106, the merging tool builds a temporary merging table containing entries corresponding to the merging Domain #1 accounts. Each entry comprises a merged account name. It is noted that in the event that a name for a merged account is changed, the new account name is placed in the temporary merging table. In addition, each entry for a merged account includes an old relative ID corresponding to the account in Domain #1 and a new relative ID corresponding to the account in Domain #2. For example, when an account is created in Domain #2 for the User 8 during step 106, the merging tool creates an entry in the temporary merging table having a name "Bob", an old relative ID of "1", and a new relative ID "13." Though the temporary merging table is not necessary for carrying out the present invention, it reduces the searching performed by the merging tool in order to locate relative IDs corresponding to merged account names during later steps of the domain merge process.” “As a result, when domains are merged and an account is assigned a new SID, access to protected resources using ACLs based upon the old SID will be lost. Therefore, adding a previously used SID to the account security data structure and creating a context based upon both the new and previously used SIDs for an account ensures that access to any protected resource is maintained (via the stored previous SID) even after the domain with which the account was previously associated is merged into another domain.”)(e.g., e.g., figures 2-4 and 8 and col 11 lines 14-30 and 48-57).
Claims 11-14, 17 and 18 have substantially similar limitations as stated in claims 2-5, 8 and 9, respectively; therefore, they are rejected for the same reasons.
Regarding claim 19, Swift discloses a system comprising a computer program product including a memory and a processor for executing instructions stored in the memory, the instructions causing a computer to perform: (“The present invention generally relates to computer object maintenance facilities, and more particularly to methods for maintaining previously established relationships between computer resources when maintenance objects are reconfigured in a computer network.”)(e.g., figures 1 and 6 and col 1 lines 7-11)
assigning, by an entity identifier (EID) assignment engine, a first entity identifier to a first data item in a multitenant EID lineage-persistent relational database management system (RDBMS); (“The File Server 6 accesses a directory service of objects database 7 ("database 7") which is preferably stored on a hard drive accessed by the File Server 6, in order to authenticate user and service logon credentials and provide security contexts after authenticating the logon credentials. The database 7 stores known account information enabling the File Server 6 (the Domain #1 controller) to authenticate user and service logon names and associated passwords and then build security contexts for the authenticated logged on users and services. Thus, the database 7 is accessed by the File Server 6 (in its role as the Domain #1 controller) in order to authenticate user and service account credentials and to create a security context when a user or service, such as User 8, 10, or 12, attempts to log onto the Domain #1.” “Domain #2, enclosed by the box 4, includes a File Server 18. The File Server 18, which also performs the functions described above associated with a domain controller, also includes a directory service of objects database 19 ("database 19"). Database 19 contains the same type of account security information described above for the database 7. The information in the database 19 facilitates authentication of user and service logons by the Domain #2 controller (File Server 18) and creating security contexts for authenticated logged on users and services associated with Domain #2. Domain #2 comprises Users 20, 22, 24, 26, 28, 30, 32, 34, and 36. Domain #2 also comprises a Print Server 38 and an SQL Server 40. Domain #2 also includes a Group 41 comprising the Users 30, 32 and 34. The Group 41 has the name "Instructors."”)(e.g., figures 2-4 and col 5 lines 31-44 and 53-67)
maintaining, by a legacy EID retention engine comprising a legacy EID survivorship subengine and a lineage EID promotion subengine, the first EID during survivorship and lineage EID promotion processes in [[a]]the multitenant EID lineage-persistent RDBMS; (“if an account is transferred to a new domain during a domain merge operation, then the former SID for the account is appended to the Group List 56. The transferred account is associated with a new Domain ID corresponding to the new domain and a new relative ID is inserted within the Current Relative ID field 54 for the transferred account. Each time the account is transferred to a new domain (necessitating assigning a new SID to the account), the former SID is added to the Group List 56 by a merging tool. The former SIDs are present in security contexts accompanying user or service requests and therefore enable users and services to maintain access to protected network resources when the ACLs of the protected network resources have not been updated to include the new SIDs assigned to transferred accounts during a domain merge procedure.” )(e.g., figures 2-4 and col 7 lines 36-51)
changing, by a data item update engine, data items, including merging the first data item in the multitenant EID lineage-persistent RDBMS with a second data item in the multitenant EID lineage-persistent RDBMS that has a second EID, which triggers survivorship and lineage EID promotion, wherein when the first data item is merged with the second data item in the multitenant EID lineage-persistent RDBMS, the first EID is promoted to primary EID of the merged data item by the lineage EID promotion subengine, and wherein when the first data item is merged with the second data item in the multitenant EID lineage-persistent RDBMS, the second EID is retained as a second legacy EID of a second data item portion of the merged data item by the legacy EID retention engine, thereby facilitating cross-tenant durability within the multitenant EID lineage-persistent RDBMS. (“Furthermore during step 106, the merging tool builds a temporary merging table containing entries corresponding to the merging Domain #1 accounts. Each entry comprises a merged account name. It is noted that in the event that a name for a merged account is changed, the new account name is placed in the temporary merging table. In addition, each entry for a merged account includes an old relative ID corresponding to the account in Domain #1 and a new relative ID corresponding to the account in Domain #2. For example, when an account is created in Domain #2 for the User 8 during step 106, the merging tool creates an entry in the temporary merging table having a name "Bob", an old relative ID of "1", and a new relative ID "13." Though the temporary merging table is not necessary for carrying out the present invention, it reduces the searching performed by the merging tool in order to locate relative IDs corresponding to merged account names during later steps of the domain merge process.” “As a result, when domains are merged and an account is assigned a new SID, access to protected resources using ACLs based upon the old SID will be lost. Therefore, adding a previously used SID to the account security data structure and creating a context based upon both the new and previously used SIDs for an account ensures that access to any protected resource is maintained (via the stored previous SID) even after the domain with which the account was previously associated is merged into another domain.”)(e.g., e.g., figures 2-4 and 8 and col 11 lines 14-30 and 48-57).
Regarding claim 20, Swift discloses the system of claim 19. Swift further discloses wherein when the first data item is merged with the second data item, the first EID is retained as a first legacy EID of a first data item portion of the merged data item. (“The group SIDs that were present within the Group List 56 before the account was merged into a new domain are retained in the Group List 56.” “Therefore, adding a previously used SID to the account security data structure and creating a context based upon both the new and previously used SIDs for an account ensures that access to any protected resource is maintained (via the stored previous SID) even after the domain with which the account was previously associated is merged into another domain.”)(e.g., figures 2-4 and col 7 lines 33-35 and col 11 lines 51-57).
Conclusion
The prior art made of record, listed on form PTO-892, and not relied upon is considered pertinent to applicant's disclosure.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to RICHARD L BOWEN whose telephone number is (571)270-5982. The examiner can normally be reached Monday through Friday 7:30AM - 4:00PM EST.
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, Aleksandr Kerzhner can be reached at (571)270-1760. 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.
/RICHARD L BOWEN/ Primary Examiner, Art Unit 2165
Prosecution Insights