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 .
Information Disclosure Statement
The Information Disclosure Statement (IDS) submitted on 11/18/24 is in compliance with the provisions of 37 CFR 1.97. Accordingly, the IDS statement has been considered by the Examiner.
Double Patenting
The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the "right to exclude" granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory double patenting rejection is appropriate where the conflicting claims are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).[AltContent: rect]
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on nonstatutory double patenting provided the reference application or patent either is shown to be commonly owned with the examined application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. See MPEP § 717.02 for applications subject to examination under the first inventor to file provisions of the AIA as explained in MPEP § 2159. See MPEP § 2146 et seq. for applications not subject to examination under the first inventor to file provisions of the AIA . A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b).
The filing of a terminal disclaimer by itself is not a complete reply to a nonstatutory double patenting (NSDP) rejection. A complete reply requires that the terminal disclaimer be accompanied by a reply requesting reconsideration of the prior Office action. Even where the NSDP rejection is provisional the reply must be complete. See MPEP § 804, subsection I.B.1. For a reply to a non-final Office action, see 37 CFR 1.111(a). For a reply to final Office action, see 37 CFR 1.113(c). A request for reconsideration while not provided for in 37 CFR 1.113(c) may be filed after final for consideration. See MPEP §§ 706.07(e) and 714.13.
The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/ patent/patents-forms. The actual filing date of the application in which the form is filed determines what form (e.g., PTO/SB/25, PTO/SB/26, PTO/AIA /25, or PTO/AIA /26) should be used. A web-based eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about eTerminal Disclaimers, refer to www.uspto.gov/ patents/apply/applying-online/eterminal-disclaimer.
Claims 1-20 are rejected on the ground of nonstatutory obviousness-type double patenting as being unpatentable over claims 1-20 of U.S. Patent No. 12147561 in view of Goel; Anil et Al. US 20150026215 (hereinafter Goel).
U.S. Patent No. 12147561 does not teach; however, Goel discloses: automatically controlling the identity management mechanism to generate at least one privileged account, including at least one credential rule, for the at least one user identity based on the at least one credential management policy (“Many database management systems also include a database administrator (DBA) account (privileged account), with unlimited power over the database. The DBA often possesses the privilege to reset a user's password” Goel. Para. 5)
automatically connecting the identity management mechanism to the database to provision the database with the at least one user identity (Goel. Para. 5)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Patent No. 12147561 with the teaching of Goel to meet the preceding limitations. One of ordinary skill in the art would have been motivated to make such modification since such techniques were known at the time of the instant invention and would have been applied in a predictable manner to “ensure the integrity, security, and performance of the database system” (Goel: para. aera. 23).
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.
Claims 1, 4, 7, 11, 14 and 17 are rejected under 35 U.S.C. 103 as being unpatentable over Pitre; Ashutosh US 9602545 (hereinafter Pitre) in view of Lindsay; Jeffrey Dean US 20070250920 (hereinafter Lindsay) and further in view of Goel; Anil et l. US 20150026215 (hereinafter Goel).
As per claim 1, Pitre discloses: A method comprising:
obtaining, by at least one processor using an orchestrator of database provisioning system, from an identity governance platform, at least one user identity according to at least one security configuration from a secret vault stored in the identity governance platform (“Computing system 100 includes identity management (IDM) system 112. IDM system 112 may implement techniques for managing user access to resources provided by one or more target systems. In certain embodiments, IDM system 112 may provide a unified, integrated computing system for managing user identities, enable policy-based automated provisioning of resources to user identities with fine-grained entitlements, and support governance and compliance across the target systems. For example, IDM system 112 may be used by an enterprise to control and manage access to resources provided for the enterprise.” Pitre: col. 7, lines 9-19);
provisioning, by the at least one processor using the orchestrator, the database with the at least one user identity according to the at least one security configuration by:
generating at least one user identity data record of the at least one user identity via an identity management mechanism associated with the database based on the at least one security configuration associated with the at least one user identity (“In some embodiments, upon identification of set of access policies 222 applicable to roles 220, each access policy in set of access policies 222 may be linked or associated with one of accounts 206 to be managed by the access policy. For example, policy profile 210 may be updated to include information (e.g., a record) that indicates an association between an access policy and an account. For example, record 212 may be added to policy profile 210 to indicate an association of access policy 208(2) to account 206(2). Record 214 may be added to policy profile 210 to indicate an association of access policy 208(1) to account 206(1). Accounts 206(1), 206(2) are now linked to an access policy.” Pitre: col. 16, lines 30-41);
Pitre does not explicitly teach; however Lindsay discloses: wherein the at least one user identity data record specifies at least one credential management policy (“The user account data 74 includes records comprising identity data 74A (e.g., user account numbers, user name, user address, user telephone numbers, Social Security number, etc.), one or more primary passwords 74B, one or more secondary passwords 74C, and security rules 74D to be implemented in response to use of the one or more of secondary passwords 74C and/or the one or more primary passwords 74B. The security rules 74D can be provided as directions through the central processor to govern the degree of access it permits relative to an asset (not shown). “Lindsay para. 112 and fig. 3) ;
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to Combine Pitre with the teachings of Lindsay to meet the preceding limitations. One of ordinary skill in the art would have been motivated to make such modification since such techniques were known at the time of the instant invention and would have been applied in a predictable manner to enhance the security of the system.
The Combination of Pitre and Lindsay does not teach; however, Goel discloses: automatically controlling the identity management mechanism to generate at least one privileged account, including at least one credential rule, for the at least one user identity based on the at least one credential management policy (“Many database management systems also include a database administrator (DBA) account (privileged account), with unlimited power over the database. The DBA often possesses the privilege to reset a user's password” Goel. Para. 5)
automatically connecting the identity management mechanism to the database to provision the database with the at least one user identity (Goel. Para. 5)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the Combination of Pitre and Lindsay with the teaching of Goel to meet the preceding limitations. One of ordinary skill in the art would have been motivated to make such modification since such techniques were known at the time of the instant invention and would have been applied in a predictable manner to “ensure the integrity, security, and performance of the database system” (Goel: para. aera. 23).
As per claim 4, the rejection of claim 1 is incorporated herein. Pitre teaches: the at least one user identity comprises at least one privileged account password (Pitre: Col. 9, II. 44-54, "Each of target systems 102(1) 102(N) may manage (e.g., store, create, read, update, or delete) account data 104(1) 104(N), respectively. Account data 104(1) 104(N) may be collectively referred to as account data 104. Account data may include information about one or more accounts provided by a target system. Account data may indicate one or more attributes associated with an account such as the owner (user identity) of the account, a start-date and end-date of the account, an account identifier, a login name for the account, a password for the account, and other like information. Pitre: Col. 9, II. 8-24, "An account may be associated with an entitlement e.g., an access privilege or a usage right) to a resource provided by a target system. An entitlement associated with an account may provide a user associated with the account a right (e.g., a privilege or a usage right) to perform an operation with respect to a resource provided by the target system. An operation with respect to a resource may correspond to a functionality or a capability related to use of the resource. An account may control access to a resource type based on the entitlement granted to the resource type by the account. In some embodiments, an account may be assigned multiple entitlements. In some embodiments, an entitlement to access a resource type may be granted to an account based on a role or responsibility of the user associated with the account. The role or responsibility of a user may one which is defined by an organization.").
As per Claim 7, the rejection of claim 1 is incorporated herein. Pitre teaches: determining, by the at least one processor based on the at least one credential management policy, (Pitre: Col. 9, II. 32-36, "In some embodiments, an entitlement to a resource type may be managed by one or more access policies. An access policy may be associated with one or more account types. An access policy may control access to and use of a resource type corresponding to an account type.") Examiner submits the "access policy" of Pitre is at least one credential management policy" "the at least one access credential rule from a set of access credential rules (Pitre: Col. 16, II. 2-29, "IDM system 112 may manage role information that indicates one or more roles (e.g., role(s) 220) associated with a user identity. IDM system 112 may determine one or more roles associated with an identity of a user indicated by each of accounts 206. In some embodiments, policy profile 210 may indicate the role(s) associated with a user identity indicated by each of accounts 206. The role(s) 220 associated with an identity of a user may be compared to roles indicates by each access policy in the set of access policies 222 to identify access policies applicable to those roles 220 associated with an identity of the user. The identified access policies may be linked to accounts 206(1), 206(2). In some examples shown in FIG. 2, access policy 208(1) (e.g., access policy 1) and access policy 208(2) (e.g., access policy 2) may be identified as applicable to roles 220 matching a role associated with an identity of a user indicated by the accounts 206. In some embodiments, processing may be performed to choose an access policy from the identified access policies applicable to roles 220. An access policy may be chosen from the identified access policies based on a priority corresponding to each of the identified access policies. The priority of an access policy may be defined by an organization, which defines the roles for enabling access based on the access policy. In at least one embodiment, an access policy with the highest priority may be chosen from the identified access policy.")
Examiner submits that "the roles for enabling access based on the access policy" of Pitre are "at least one access credential rule" and that the plurality of the roles described in Pitre corresponds to "a set of access credential rules.
As per claim 11, this claim defines a system corresponding to method of claim 1 and does not define beyond limitations of claim 1. Therefore, claim 11 is rejected with the same rational as in the rejection of claim 1.
As per claim 14, this claim defines a system corresponding to method of claim 4 and does not define beyond limitations of claim 4. Therefore, claim 14 is rejected with the same rational as in the rejection of claim 4.
As per claim 17, this claim defines a system corresponding to method of claim 7 and does not define beyond limitations of claim 7. Therefore, claim 17 is rejected with the same rational as in the rejection of claim 7.
Claims 2-3, 9-10, 12-13 and 19-20 are rejected under 35 U.S.C. 103 as being unpatentable over Pitre in view of Lindsay in view of Goel and further view of Knox et al. Applied Oracle Security: Developing Secure Database and Middleware Environments, McGraw Hill Computing, November 2009 hereafter KNOX.
As per claim 2, the rejection of claim 1 is incorporated herein. Pitre teaches: wherein the at least one credential identity comprises programmatic access credential identities comprising: i)
(Pitre: Col. 16, II. 23-29, "An access policy may be chosen from the identified access policies based on a priority corresponding to each of the identified access policies. The priority of an access policy may be defined by an organization, which defines the roles for enabling access based on the access policy. In at least one embodiment, an access policy with the highest priority may be chosen from the identified access policy. Pitre Col. II, 58-65, "For example, IDM system 112 may provide user identity information 150 of a user to a target system ( e.g., target system 102(1)) to request provisioning of an account by the target system for the user.) Pitre: Col. 7, II. 12-17 "In certain embodiments, IDM system 112 may provide a unified, integrated computing system for managing user identities, enable policy-based automated provisioning of resources to user identities with 15 fine- grained entitlements, and support governance and compliance across the target systems").
iii) application access identity, (Pitre Col 8, II. 43-50, "One or more types of accounts may be provisioned for a target system based 45 upon the resources provided by the target system. These account types may include, for example, various user accounts, administrative accounts, application accounts, and the like, with each account type providing a particular level of access to one or more resources provided by the target 50 system.")
Pitre, Lindsay and Goel do not expressly teach:
i) master database identity,
ii) shared database identity and iv) reconciliation account identity.
However, in a similar art KNOX teaches:
i) master database identity,
KNOX Ch. 1, p. 19 "Object owner accounts are the accounts that you typically think of when you think of database schemas. The accounts serve as a container for execution code and other database objects such as tables, views, indexes, triggers, and so forth, that are part of an application or database option. The default database accounts that end in "SYS", which includes the schema SYS, are examples of object owner accounts. These accounts are often synonymous with a database option. For example, CTXSYS is the schema for the (Con) database option, MDSYS is the schema for the Spatial data option, and SYS is the schema for the database engine itself.") Examiner submits that a person having ordinary skill in the art would recognize that the SYS schema of an Oracle database is the "master database identity."
ii) shared database identity, (KNOX Ch. 1, p.22, "Dedicated Accounts and Shared Accounts, "Irrespective of how the users connect, they will be connected either to a dedicated account or a shared account. At the risk of stating the obvious, a dedicated account associates one distinct user with one distinct account. A shared account is used when users share the same functional roles and thus the same sets of privileges." KNOX Ch. 1, p. 23, "It has long been argued that you should not allow users to share accounts. Whether you agree with this or not, shared accounts happen quite frequently, especially when the users share functions and thus privileges. The scary aspect of shared accounts is that they are often applied to administrator accounts such as root, SYS, or SYSTEM for the database. Shared accounts allow multiple users to access the same account but in doing so, it obfuscates their unique identities. This would therefore limit, if not altogether defeat, any auditing. If someone does something bad, no one knows for sure who did it.
Nevertheless, shared accounts still make sense for manageability reasons, and you can employ such techniques as setting the CLIENT_IDENTIFIER to propagate the real end user's identity. Another prime example on UNIX systems is the use of SUDO, which allows users to execute privileged commands (run as root)
while preserving their identity. "); and
iv) reconciliation account identity (KNOX Ch 9 p. 20, "Reconciliation Integrations, "Two types of system integrations are supported by OIM: provisioning and reconciliation. Provisioning automates account creation from the OIM server to an application or resource using the data from the OIM repository. Reconciliation automates the creation of an OIM identity record based on an external source of identities (that is, a source of truth). Most often, OIM reconciles from an external human resources application as an authoritative source of employee data and then provisions to business productivity applications, such as email, intranet portals, and other ERP systems.") Examiner submits that the OIM has its own account identity.
Pitre, Lindsay, Goel, and KNOX are in the similar field of endeavor and related to the technology of secure databases It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the features described by KNOX into the invention of Pitre, Lindsay, Goel by adding various identities based upon the needed goal.
As per claim 3, the rejection of claim 1 is incorporated herein. Pitre teaches:
wherein the at least one credential identity comprises user access credential identities comprising:
and ii) at least one user account identity (Pitre: Col 8, II. 43-50, "One or more types of accounts may be provisioned for a target system based 45 upon the resources provided by the target system. These account types may include, for example, various user accounts, administrative accounts, application accounts, and the like, with each account type providing a particular level of access to one or more resources provided by the target 50 system. ) Examiner submits that a user account will be associated with a username and hence a "credential identity."
Pitre, Lindsay and Goel do not expressly teach:
i) an automation server identity,
However, in a similar art, KNOX teaches: i) an automation server identity," KNOX Ch 9, Reconciliation Integrations, "Provisioning automates account creation from the OIM server to an application or resource using the data from the OIM repository. Reconciliation automates the creation of an OIM identity record based on an external source of identities (that is, a source of truth)") Examiner submits, both reconciliation and provisioning are automated functions of the OIM server, the OIM identity of KNOX is related to the OIM server of KNOX and is therefore an automation server identity.
Pitre, Lindsay, Goel, and KNOX are in the similar field of endeavor and both related to the technology of secure databases It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the features described by KNOX into the invention of Pitre, Lindsay, Goel by adding various identities based upon the needed goal. Based on the KSR V. TELEFLEX rationale, such an addition uses known methods (different database identities) to produce a predictable result (segregate database access to increase database security).
As per claim 9, the rejection of claim 1 is incorporated herein. The Combination of Pitre, Lindsay and Goel does not teach further comprising automatically instantiating, by the at least one processor, an automated database onboarding tool to produce API requests associated with an automated onboarding API set to: automatically identify one or more security services, automatically provide the identity data record and at least one compliance policy to the one or more security services, and automatically cause the one or more security services to configure account access to the database for the identity data record according to at least one compliance policy. However, in a similar art KNOX teaches: further comprising automatically instantiating, by the at least one processor, an automated database onboarding tool to produce API requests associated with an automated onboarding API set to: (KNOX Ch. 9, p. 1, "When a new employee joins a company, she needs an office, a computer, office supplies, an e-mail address, access to business applications, and so forth. This process goes by many names-such as on-boarding or hire-to-retire. User provisioning is a subprocess initiated by the on-boarding or hire-to-retire process that deals specifically with giving users access to resources. KNOX Ch. 9, p. 2, "OIM is a fundamental building block for an overall identity management solution. Access management, role management, directory services, and entitlement management all depend on having a working user provisioning solution that ensures the right identity data exists in the right location for other solutions to use. KNOX Ch. 9, p. 26, "Business Logic Tier This tier is the core of the OIM product. In this tier, OIM decides who (the user) to provision where (target resource) and how(the process). This tier is written exclusively in Java and leverages a J2EEdesign pattern and therefore inherits the core benefits of that Combination-platform-neutrality and distributed component architecture. A Java-based OIM business tier allows a standard development platform for new integration connectors and adapters. The distributed nature of J2EE allows for the business logic tier to be spread across multiple application server deployments while accessing the common metadata from the data tier.") Examiner submits "OIM" is an automated database onboarding tool. The "tier is written exclusively in Java" is the API that may "produce API requests associated with an automated onboarding API" when deployed.
automatically identify one or more security services, automatically provide the identity data record and at least one compliance policy to the one or more security services, and automatically cause the one or more security services to configure account access to the database for the identity data record according to at least one compliance policy. (KNOX Ch. 9, p.15, "To address this issue, corporate security has to lend a hand by providing us a set of access policies that define rules regarding "who should access what." Once those policies are defined, you can implement them very easily in OIM through the web administrative console's Access Policies section. The following high-level steps are required to set up an access policy: 1. Go to the Create Access Policy section in the OIM administrative console. 2. Select the resource(s) to be provisioned under the chosen access policy, as shown in Figure 9- 8. 3. Set the date this for which access needs to be issued. 4. Select the resource(s) that should be denied to the user through this access policy. 5. Select the user groups that apply to this access policy, as shown in Figure9-9. Once you have defined these four facets of the access policy (what is provisioned, when it is issued, what not to be provisioned, and who this is for), you are ready to automate the majority of your enterprise user provisioning through a collection of these access policies. If you have defined the approval workflows, the access policies will automatically trigger those flows to be routed through the appropriate authorities.) Examiner submits that the "appropriate authorities" of KNOX are the "one
or more security services." The "user" of KNOX is the "identity data record." The "access policy" of KNOX is the "at least one compliance policy."
Pitre, Lindsay, Goel, and KNOX are in the similar field of endeavor and both related to the technology of secure databases. It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the features described by KNOX into the invention of Pitre, Lindsay, Goel by delegating the onboarding to the OIM of KNOX. Based on the KSR V. TELEFLEX rationale, such an addition uses known methods (having an application mediate between multiple datasets) to produce a predictable result (automate onboarding ).
As per Claim 10, the rejection of claim 1 is incorporated herein. The Combination of Pitre, Lindsay, Goel does not teach; however, in a similar art KNOX teaches: further comprising onboarding, by the at least one processor, an identity governance platform to implement the at least one access credential rule (KNOX Ch. 9, p. 2, "OIM is a fundamental building block for an overall identity management solution. Access management, role management, directory services, and entitlement management all depend on having a working user provisioning solution that ensures the right identity data exists in the right location for other solutions to use. KNOX Ch. 9, p. 7, "In addition to controlling the resource, you can also control each user's privileges within each resource by associating application-level privileges to user groups in the access policy. For example, suppose two user groups, "Data Analyst" and "Data Administrator," should both be provisioned to access the same database application but with different database roles(such as analyst and DBA). You can set that mapping of user group to database roles inside an access policy." ) Examiner submits that the "database roles" of KNOX are an "access credential rule." The OIM of KNOX is an "identity governance platform."
Pitre, Lindsay, Goel, and KNOX are in the similar field of endeavor and both related to the technology of secure databases. It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the features described by KNOX into the invention of Pitre, Lindsay, Goel by delegating the onboarding to the OIM of KNOX to implement the access credential rule. Based on the KSR V. TELEFLEX rationale, such an addition uses known methods (having an application mediate between multiple datasets) to produce a predictable result (automate onboarding ).
As per claim 12, this claim defines a system corresponding to method of claim 2 and does not define beyond limitations of claim 2. Therefore, claim 12 is rejected with the same rational as in the rejection of claim 2.
As per claim 13, this claim defines a system corresponding to method of claim 3 and does not define beyond limitations of claim 3. Therefore, claim 13 is rejected with the same rational as in the rejection of claim 3.
As per claim 19, this claim defines a system corresponding to method of claim 9 and does not define beyond limitations of claim 9. Therefore, claim 19 is rejected with the same rational as in the rejection of claim 9.
As per claim 20, this claim defines a system corresponding to method of claim 10 and does not define beyond limitations of claim 10. Therefore, claim 20 is rejected with the same rational as in the rejection of claim 10.
Claims 5, 6 ,15 and 16 are rejected under 35 U.S.C. 103 as being unpatentable over Pitre in view of Lindsay in view of Goel and further view of Adler; Israel Martin et al. US 9305160 (hereinafter Adler).
As per claim 5, the rejection of claim 4 is incorporated herein. The Combination of Pitre, Lindsay and Goil does not teach; however, Adler discloses: password reset periods for the at least one privileged account password (ADLER Col. 10 II. 22-38, "If an action has occurred that is not the updating of a user profile 208, then, in step 312, the processor 204 may determine if a custom interval 222 in one or more account data entries 216 of one or more user profiles 208 has expired. The expiration of a custom interval 222 may be identified by a custom interval 222 counting down to Zero, a current time and/or date exceeding a time and/or date set in the custom interval 222, a predetermined period of time in a custom interval 222 having passed since a timestamp for a previous password change, or other suitable method. If a custom interval 222 has expired, then, in step 314, the processor 204 may generate a random password for each account data entry 216 in each user profile 208 where the included custom interval 222 has expired.")
Pitre, Lindsay, Goil, and ADLER are in the similar field of endeavor and are related to the technology of secure databases It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the features described by ADLER into the invention of Pitre, Lindsay, Goil by adding the password expiry and new password generation of ADLER. Based on the
KSR V. TELEFLEX rationale, such an addition uses known methods (expiring passwords and generating new strong passwords) to produce a predictable result (increase database security).
As per claim 6, the rejection of claim 5 is incorporated herein. The Combination of Pitre, Lindsay and Goil does not teach; however, Adler discloses: automatically generating, by the at least one processor, new passwords for accessing the at least one privileged account based on the password reset periods (ADLER Col. 10 II. 22-38, "If an action has occurred that is not the updating of a user profile 208, then, in step 312, the processor 204 may determine if a custom interval 222 in one or more account data entries 216 of one or more user profiles 208 has expired. The expiration of a custom interval 222 may be identified by a custom interval 222 counting down to Zero, a current time and/or date exceeding a time and/or date set in the custom interval 222, a predetermined period of time in a custom interval 222 having passed since a timestamp for a previous password change, or other suitable method. If a custom interval 222 has expired, then, in step 314, the processor 204 may generate a random password for each account data entry 216 in each user profile 208 where the included custom interval 222 has expired.")
Pitre, Lindsay, Goil, and ADLER are in the similar field of endeavor and both related to the technology of secure databases It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the features described by ADLER into the invention of Pitre, Lindsay, Goil by adding the password expiry and new password generation of ADLER. Based on the
KSR V. TELEFLEX rationale, such an addition uses known methods (expiring passwords and generating new strong passwords) to produce a predictable result (increase database security).
As per claim 15, this claim defines a system corresponding to method of claim 5 and does not define beyond limitations of claim 5. Therefore, claim 15 is rejected with the same rational as in the rejection of claim 5.
As per claim 16, this claim defines a system corresponding to method of claim 6 and does not define beyond limitations of claim 6. Therefore, claim 16 is rejected with the same rational as in the rejection of claim 6.
Claims 8 and 18 are rejected under 35 U.S.C. 103 as being unpatentable over Pitre in view of Lindsay in view of Goel and further view of COMBSS; John S. US 20220091896 (hereinafter Combs).
As per claim 8, the rejection of claim 1 is incorporated herein. The Combination of Pitre, Lindsay and Goel does not teach; however, Coms discloses: deploying, by the at least one processor upon disconnecting from a secured port, the database using a continuous integration continuous deployment pipeline (“Embodiments may provide a cloud-agnostic user experience with common taxonomies; may offer flexibility to experiment in multiple cloud environments; may enable a consistent experience for various personas (e.g., developer, financial analyst, compliance officer, etc.); may provide access to best-in-class provider agnostic cloud management and operations tools; may provide a transparent view of to-date and projected costs at the device and hourly levels; may allow application teams to deploy infrastructure into continuous integration/continuous development (CI/CD) pipelines; may leverage leverage-leading edge services, such as natural language processing, big data analytics, and AI; and may be the system of record for cloud configuration management database (CMDB) that supports request and incident (disconnecting from a secured port) processes as well as support “Get to Moderate” (GtM) goals and objectives.”. Combs: para. 38).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the Combination of Pitre, Lindsay and Goel with the teaching of Combs to meet the preceding limitations. One of ordinary skill in the art would have been motivated to make such modification since such techniques were known at the time of the instant invention and would have been applied in a predictable manner to secure the data communication.
As per claim 18, this claim defines a system corresponding to method of claim 8 and does not define beyond limitations of claim 8. Therefore, claim 18 is rejected with the same rational as in the rejection of claim 8.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to GHODRAT JAMSHIDI whose telephone number is (571)270-1956. The examiner can normally be reached 10:00-6:00.
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, Carl Colin can be reached at 5712723862. 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.
/GHODRAT JAMSHIDI/Primary Examiner, Art Unit 2493
Prosecution Insights