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 .
1. The text of those sections of Title 35 U.S.C not included in this section can be found in the prior office action.
2. The prior office actions are incorporated herein by reference. In particular, the observations with respect to claim language, and response to previously presented arguments.
Claims 1 and 11 have been amended.
New claims have been added.
No claims have been cancelled.
Claims 1-20 are pending.
Response to Arguments
The Double Patenting rejection of the pending claims has been removed in light of approval of the terminal disclaimer filed by applicant.
Applicant’s arguments filed on 8/12/2026 with respect to prior art rejections of the amended claims are moot in light of new ground of rejection.
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) in view
of Goel; Anil et I. US 20150026215 (hereinafter Goel) and further in view of Perlmuter; Ron. Et al. US 9838383 (hereinafter Perlmuter).
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).
The Combination of Pitre, Lindsay and Goel does not teach; however, Perlmuter discloses: use an access manager API associated with a privileged access management service for managing privileged user access to the database to provide the at least one privileged account and associated credentials to the privileged access management service (“a PIM server includes a centralized server which controls access to privileged accounts through password rotations and modifications of login permissions. The PIM server includes a password vault that stores the current passwords for privileged accounts. The PIM server also includes a password rotation component that modifies privileged account passwords on target endpoints according to predetermined password policies. The PIM server additionally includes an access control lists (ACL) rotation component that modifies privileged account login policies on target endpoints based on user permissions. The PIM server further includes a PIM portal that displays to users which privileged accounts they have access to. The PIM server also includes an authorization policy that controls user access to privileged accounts.” Perlmuter: col.8, lines 47-61);
wherein the privileged access management service vaults the at least one privileged account and associated credentials in a vault or secrets vaulting mechanism (Perlmuter: col.8, lines 47-61); and
wherein the privileged access management service manages privileged
accounts, access and actions in accordance with organizational policy by
controlling privileged credentials and supporting workflows including password
replacement and password rotation and rotation policies (Perlmuter: col.8, lines 47-61).
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 Perlmuter 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 manage and secure access credentials.
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 in view of Lindsay in view of Goel in view of Perlmuter and further in 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").
ii
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, Goel and Perlmuter 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 9p. 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, Perlmuter 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 and Perlmuter 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, Goel and Perlmuter 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, Perlmuter, 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 and Perlmuter 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, Goel and Perlmuter 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, Perlmuter 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 and Perlmuter 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 and Perlmuter 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, Perlmuter 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 and Perlmuter 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 in view of Perlmuter 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, Goil and Perlmuter 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, Perlmuter 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 and Perlmuter 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, Goil and Perlmuter 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, Perlmuter, 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 and Perlmuter 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 in view of Perlmuter 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, Goel and Perlmuter 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 Al; 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,
Goel and Perlmuter 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
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). 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 nonprovisional extension fee (37 CFR 1.17(a)) 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 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