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 04/25/2025 has been entered.
Status of Claims
The following is a Non-Final Office Action in response to applicant’s filing on April 25, 2025. Claims 1-5, 8-12, and 15-18 were amended. Claims 1-20 are pending, of which claims 1, 8 and 15 are in independent form.
Response to Amendment
Applicant’s amendment regarding claim 1, 8, and 15 obviates the claim rejection, therefore the claim rejection under 35 USC § 112(a) is withdrawn.
Applicant’s amendment regarding claim 1, 8, and 15 obviates the claim rejection, therefore the claim rejection under 35 USC § 112(b) is withdrawn.
Response to Arguments
Applicant’s arguments with respect to claim(s) are rejected, under 35 USC 103(a), have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter.
On page 10 of remarks, Applicant argues that “Geusz and Aupperle, take alone or in combination, do not teach or suggest the above- presented features of independent Claims 1, 8, and 15 “a plurality of accounts each comprising a user identification value of an unauthorized user and a processing action; executing a process based on a request by a user associated with an account of the plurality of accounts; monitoring process information relating to the process, wherein monitoring the processing information relating to a process comprises monitoring a security protocol used during an authentication of the process; determining the security protocol used during the authentication, wherein the security protocol is a first security protocol or a second security protocol, and wherein the first security protocol requires an accessor environment element (ACEE) to be used; identifying an instance in which the second security protocol is used in the authentication; identifying, based on the identified instance, the account comprising user identity information associated with the user; mimicking an ACEE for the process using the user identity information; and authenticating the process via the first security protocol using the ACEE” as recited in the independent claims 1, 8, and 15.
Applicant’s arguments, with respect to the rejection(s) of claim(s) 1, 8, and 15 have been fully considered and are persuasive. Therefore, the rejection has been withdrawn. However, upon further consideration, a new ground(s) of rejection is made in view of Guski et al. (US 2010/0180329 A1).
As to the dependent claims, these claims remain rejected by virtue of dependency to their independent claims. Therefore, the examiner maintains the rejection under 35 USC § 103.
Regarding the combination of Geusz, Aupperle and Guski with respect to claims 1, 12, and 17, it is applicant’s opinion that adding the Aupperle and Guski references provides no reasonable combination. However, a person of ordinary skill is also a person of ordinary creativity, not an automaton, and in many cases will be able to fit teaching of multiple patents together like pieces of a puzzle. Furthermore, “The test for obviousness is not whether the feature of secondary reference may be bodily incorporated into the structure of the primary reference…Rather, the test is what the combined teachings of those references would have suggested to those of ordinary skill in the art”. In the instant case Geusz provides additional information that would suggest a modification of Aupperle and Guski.
In addition, Applicant’s argument regarding alleged invention feature of modifying the db2 exit routine to mimic an ACEE have been fully considered but are not persuasive. The paragraphs [0029], [0056], and [0057] of the instant application merely describe that in an instance where RACF is the first security protocol and the second protocol is used, the standard db2 is modified to identify user identity information. There is no steps or algorithm as to how the db2 exit routine is modified nor as the how an ACEE is mimicked. Moreover, Aupperle teaches The TN3270 server is adapted for monitoring inbound client data for presence of the sign-on screen and placeholders in the 3270 data stream that is to be transmitted from the client. Upon detecting the presence of the placeholders, the TN3270 server locates the client's cached digital certificate, and passes this cached certificate to the host-based RACF software 160 over the established SNA session. The RACF system extracts the subject field of the client certificate, and uses this information to locate the user's stored credentials and access privileges, see paragraph [0062]. Accordingly, there is no inventive step for the first security protocol and the modification of the db2 exit routine is found. Therefore, the rejection under 35 U.S.C. § 103 is maintained.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION. — The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 1-20 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Claim 1 recites the limitation “unauthorized user” is not definite by the claim. In addition, there is nothing in the specification to define the relativeness creating account for unauthorized users. Additionally, it is not clear whether the user as an “unauthorized user” is the same as “user” cited in claim. The examiner encourages Applicant to clarify the difference between “unauthorized user” and “user” to rectify the issue. The same reasons apply to independent claims 8 and 15.
Claim 1 recites the limitation “identifying an instance” and “identify, based on the instance” is not definite by the claim. The term “an instance”, can have many different meanings and the specification does not clearly define “identifying an instance” and “identify, based on the instance”. In addition, the language does not define a certainty and the metes and bounds of the claim are unascertainable. It is not clear when the occurrence of the second security protocol has happened to make an authentication. Therefore, it is unclear what is the intended scope of the claim invention. The same reasons apply to independent claims 8 and 15, and the dependent claims at least virtue of their dependencies. The same reasons apply to independent claims 8 and 15.
Claim 2 recites the limitation “the second security protocol is used in an instance in which the ACEE is not provided”. The term “an instance”, can have many different meanings and the specification does not clearly define “an instance”. In addition, the language does not define a certainty and the metes and bounds of the claim are unascertainable. It is not clear when the occurrence of the second security protocol has happened when the ACEE is not provided. Therefore, it is unclear what is the intended scope of the claim invention. The same reasons apply to dependent claims 9 and 14.
Claim 2 recites the limitation “a transmission of a notification in an instance in which the second security protocol is used in the authentication”, can have many different meanings and the specification does not clearly define “an instance”. In addition, the language does not define a certainty and the metes and bounds of the claim are unascertainable. It is not clear when a transmission of a notification has been occurred. Therefore, it is unclear what is the intended scope of the claim invention. The same reasons apply to dependent claims 16 and 20.
The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. 112:
The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor of carrying out his invention.
Claims 1-20 are rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the written description requirement. The claim(s) contains subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for applications subject to pre-AIA 35 U.S.C. 112, the inventor(s), at the time the application was filed, had possession of the claimed invention.
Claims 1, 8, and 15 recite “identify, based on the instance, the account comprising user identity information associated with the user mimic an ACEE for the process using the user identity information and authenticate the process via the first security protocol using the mimicked ACEE”.
In MPEP 2161.01, "computer-implemented functional claim language must still be evaluated for sufficient disclosure under the written description". And MPEP 2161.01(I) "generic claim language in the original disclosure does not satisfy the written description requirement if it fails to support the scope of the genus claimed." For computer-implemented inventions, the determination of the sufficiency of disclosure will require an inquiry into the sufficiency of both the disclosed hardware and the disclosed software due to the interrelationship and interdependence of computer hardware and software. The critical inquiry is whether the disclosure of the application relied upon reasonably conveys to those skilled in the art that the inventor had possession of the claimed subject matter as of the filing date.
Claims 1, 8, and 15 recite “define a plurality of accounts each comprising a user identification value of an unauthorized user and a processing action”.
The non-provisional specification fails to provide written description support for the claim limitation of “define a plurality of accounts each comprising a user identification value of an unauthorized user and a processing action”. As to the limitation of claim 1, there is no support in the specification to define “define a plurality of accounts … of an unauthorized user”. (i.e., This authentication information may be used to authenticate the identity of the user (e.g., determine that the authentication information is associated with the account) and determine that the user has authority to access an account or system. See paragraph [0025]). The full scope of the claim covers “define a plurality of accounts each comprising a user identification value of an unauthorized user and a processing action”. However, the specification does not have support limitation and introduces new matter.
Further, the non-provisional specification fails to provide written description support for the claim limitation of “identify, based on the instance, the account comprising user identity information associated with the user mimic an ACEE for the process using the user identity information and authenticate the process via the first security protocol using the mimicked ACEE” in independent claim 1. As to the limitation of claim 1, there is no support in the specification to define any algorithm, data structure, or step for “mimicking” an ACEE. (i.e., The process code may be updated to include a user identity information based on the process and a user that requests the process. The user identity information may mimic a ACEE or other user identity that allows for the first security protocol (e.g., RACF) to authenticate the process. In various embodiments, one of the actions includes creating a user identity information based on the process. The user identity information may be created based on information provided with the process request (e.g., including information relating to a user). The user identity information may include access level to one or more process relating to a user. The one or more actions may include various other actions that allow for the first security protocol to be used for the authentication of the process. The user identity information may include a user identification value and the process (or program) involved in a transaction. See paragraph [0056]). The full scope of the claim covers “identify, based on the instance, the account comprising user identity information associated with the user mimic an ACEE for the process using the user identity information and authenticate the process via the first security protocol using the mimicked ACEE”. However, the specification does not have support such a full scope of the claim. The same reasons apply to independent claims 8 and 15.
Furthermore, claim 3 recite “wherein one or more actions to allow the authentication to use the first security protocol comprises updating a process code of a standard exit routine to identify the account to allow for the first security protocol to operate”. The non-provisional specification fails to provide written description support for the claim limitation of “the one or more actions include changes to a process code to modify standard exit routine for user information on the second security protocol;”. As to the limitation of claim 1, there is no support in the specification to define the relativeness of changes to a process code to modifies the standard exit routine and there is no steps or algorithm as to how the exit routine is modified. The invention does not explain the steps are performed to modify the standard exit routine and how a process code has been changed. (i.e., in an instance in which the first security protocol is RACF and the second security protocol is used, the standard db2 exit routine is modified to identify the user identity information and in such an instance in which the user identity information is provided, RACF is used to authenticate the process, see paragraph [0057]). The full scope of the claim covers the one or more actions include changes to a process code to modify standard exit routine for user information on the second security protocol. However, the specification does not have support such a full scope of the claim. The same reasons apply to dependent claims 10 and 17.
Note though that a claim will not be found inadequate on section 112(a) ground simply because the embodiments of the specification do not contain examples explicitly covering the full scope of the claim language. That is because the patent specification is written for a person of ordinary skill in the art, and such a person comes to the patent disclosure with the knowledge of what has come before. While a claim will not usually be limited to a particular species described in the specification, it is clear from the non-provisional specification in this application that the disclosed functions expressions are critical to the functioning of the claimed the communication between plurality of the applications and training a machine learning model based on the performance of the applications.
Further, as noted with discussion of comparison of conventional examples. Thus, given the state of this technology, one of ordinary skill in the art would not have recognized that the inventor possessed the full scope of the claimed genus. As a result, there is no evidence in the non-provisional specification that the inventor had possession of all ways and genus of performing the function.
AS in MPEP 2161.01 “For instance, generic claim language in the original disclosure does not satisfy the written description requirement if it fails to support the scope of the genus claimed. Ariad, 598 F.3d at 1349-50, 94 USPQ2d at 1171 ("[A]n adequate written description of a claimed genus requires more than a generic statement of an invention’s boundaries.") (citing Eli Lilly, 119 F.3d at 1568, 43 USPQ2d at 1405-06); Enzo Biochem, Inc. v. Gen-Probe, Inc., 323 F.3d 956, 968, 63 USPQ2d 1609, 1616 (Fed. Cir. 2002) (holding that generic claim language appearing in ipsis verbis in the original specification did not satisfy the written description requirement because it failed to support the scope of the genus claimed); Fiers v. Revel, 984 F.2d 1164, 1170, 25 USPQ2d 1601, 1606 (Fed. Cir. 1993) (rejecting the argument that "only similar language in the specification or original claims is necessary to satisfy the written description requirement").”
“The Federal Circuit has explained that a specification cannot always support expansive claim language and satisfy the requirements of 35 U.S.C. 112 "merely by clearly describing one embodiment of the thing claimed." LizardTech v. Earth Resource Mapping, Inc., 424 F.3d 1336, 1346, 76 USPQ2d 1731, 1733 (Fed. Cir. 2005). The issue is whether a person skilled in the art would understand applicant to have invented, and been in possession of, the invention as broadly claimed. In LizardTech, claims to a generic method of making a seamless discrete wavelet transformation (DWT) were held invalid under 35 U.S.C. 112, first paragraph, because the specification taught only one particular method for making a seamless DWT and there was no evidence that the specification contemplated a more generic method. "[T]he description of one method for creating a seamless DWT does not entitle the inventor . . . to claim any and all means for achieving that objective." LizardTech, 424 F.3d at 1346, 76 USPQ2d at 1733.”
As to claims 2-7, 9-14, and 16-20, these claims are rejected by virtue of dependency to independent claims 1, 8, and 15.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1-20 are rejected under 35 U.S.C. 103 as being unpatentable over Geusz et al. (US 11,159,511 B1), hereinafter Geusz in view of Aupperle et al. (US 2008/0263365 A1), hereinafter Aupperle and further in view of Guski et al. (US 2010/0180329 A1), hereinafter Guski.
In regards to claim 1, Geusz discloses a system for controlling access security protocols in a database management system, the system comprising:
at least one non-transitory storage device (Geusz, Col. 24, Lines 5-18, one or more modules of computer program instructions encoded on a tangible non-transitory program carrier for execution by, or to control the operation of, data processing apparatus. Alternatively, or in addition, the program instructions can be encoded on an artificially generated propagated signal, e.g., a machine-generated electrical, optical, or electromagnetic signal that is generated to encode information for transmission to suitable receiver apparatus for execution by a data processing apparatus. The computer storage medium can be a machine-readable storage device, a machine-readable storage substrate, a random or serial access memory device, or a combination of one or more of them); and
at least one processing device coupled to the at least one non-transitory storage device (Geusz, Col. 24, Lines 8-13, alternatively or in addition, the program instructions can be encoded on an artificially generated propagated signal, e.g., a machine-generated electrical, optical, or electromagnetic signal that is generated to encode information for transmission to suitable receiver apparatus for execution by a data processing apparatus),
wherein the at least one processing device is configured to: define a plurality of accounts each comprising a user identification value of an unauthorized user and a processing action (Geusz, Col. 4, lines 45-49, in some implementations, the method includes: communicating with multiple different services to establish authenticated sessions for the particular user for each of the different services without user action to initiate access to the multiple different services, the multiple different services using different authentication protocols):
execute a process based on a request by a user associated with an account of the plurality of accounts (Geusz, Col. 3, lines 8-16, the protocol management system can deny a user's access to a requested service found only in South America, when the user's GPS indicates his location is in Asia. In some implementations, the protocol management system may analyze the context of the user to determine whether to grant or deny access to the user. For example, context can include time of day, type of device, and type of protocol being used to request service);
monitor process information relating to the process (Geusz, Col. 11, Lines 49-53, The management server 108 analyzes the request 103 to first verify the identity of the user 102 that transmitted the request 103. In some implementations, authentication is performed by checking the username provided in the transmitted request 103), wherein monitoring the processing information relating to a process comprises monitoring a security protocol used during an authentication of the process (Geusz, Col. 1, Lines 19-25, a management server can provide a layer of abstraction to manage authentication for a user to access many resources, regardless of the specific authentication protocol required by the individual resources. As a result, the management server can automatically obtain and maintain authenticated sessions on behalf of a user across multiple authentication protocols);
determine the security protocol used during the authentication (Geusz, Col. 7, Lines 1-2, the management server 108 can determine the authentication protocol(s) used in that context and store the data),
wherein the security protocol is a first security protocol or a second security protocol (Geusz, Col. 19, Lines 58-64, a single joint session may be created that requires authentication using two different protocols. In particular, the session can involve a first communication protocol between the client device and the protocol management server 108 as well as a second communication protocol between the protocol management server 108),
Geusz does not explicitly teach identify an instance in which the second security protocol is used in the authentication; and
However, Aupperle teaches identify an instance in which the second security protocol is used in the authentication (Aupperle, Para. 0048, The client's digital certificate is required when establishing the SSL connection, according to the prior art SSL specification, to enable the TN3270 server or Web application server to authenticate the client);
Geusz and Aupperle are both considered to be analogous to the claim invention because they are in the same field of monitoring one or more security protocol used during an authentication process. Therefore, it would have been obvious to someone ordinary skill in the art before the effective filling date of the claimed invention to have modified Geusz to incorporate the teachings of Aupperle to include identify an instance in which the second security protocol is used in the authentication (Aupperle, Para. 0048). Doing so would aid to grant user access to protected legacy host applications by leveraging security tokens created when establishing secure Web-based communications. Users can then seamlessly and securely access a plurality of modern Web applications and/or legacy host applications, within a single user session, without having to identify themselves multiple times. This secure access is provided transparently to the user, who no longer has to maintain separate passwords and user IDs for accessing legacy host applications (Aupperle, Para. 0042).
Geusz and Aupperle do not explicitly teach wherein the first security protocol requires an accessor environment element (ACEE) to be used;
identify, based on the instance, the account comprising user identity information associated with the user mimic an ACEE for the process using the user identity information and authenticate the process via the first security protocol using the mimicked ACEE.
However, Guski teaches wherein the first security protocol requires an accessor environment element (ACEE) to be used (Guski, Fig. 3, Items 320, 312, and 317, and Para. 0073, the initial authentication component then sends the transaction request message 316 with the appended distributed security information 317 (step 503) via secure message protocol to the subsequent processing component 315) and (Guski, Para. 0075, the mainframe component 315 uses the distributed security information 317 to generate a lookup key within its local cache of runtime security contexts, e.g. RACF ACEE, to see if it has already processed and retained in its cache a copy of the runtime security context);
identify, based on the instance, the account comprising user identity information associated with the user mimic an ACEE for the process using the user identity information and authenticate the process via the first security protocol using the mimicked ACEE (Guski, Para. 0075, upon receiving the transaction request message 316 (step 602), the mainframe component 315 uses the distributed security information 317 to generate a lookup key within its local cache of runtime security contexts, e.g. RACF ACEE, to see if it has already processed and retained in its cache a copy of the runtime security context), It is noted that a copy or mimic of a runtime security context (ACEE) using the same secure message protocol, which corresponds to the first security protocol). Geusz, Aupperle and Guski are all considered to be analogous to the claim invention because they are in the same field of monitoring one or more security protocol used during an authentication process. Therefore, it would have been obvious to someone ordinary skill in the art before the effective filling date of the claimed invention to have modified Geusz and Aupperle to incorporate the teachings of Guski to include wherein the first security protocol requires an accessor environment element (ACEE) to be used (Guski, Fig. 3, Items 320, 312, and 317, and Para. 0073);
identify, based on the instance, the account comprising user identity information associated with the user mimic an ACEE for the process using the user identity information and authenticate the process via the first security protocol using the mimicked ACEE (Guski, Para. 0075). Doing so would aid to provide a way for identity-differentiating information, including but not restricted to that which a customer might add to the identity information that is propagated by z/OS Identity Propagation (ID Prop), to be specifically indicated as being a necessary part of the hashable portion of the propagated identity information, and for this "hashable indicator information" to be propagated along with the rest of the identity information. The advantage and novelty of the invention is that this "hashable indicator information" is thus available to receivers of propagated identities, such as CICS and IMS, so that their cache keys (previously described) can be correctly constructed dynamically according to the particular customer dictated situation (Guski, Para. 0007).
Moreover, as understood by one of ordinary skilled in the art per Applicant’s specification (paragraph [0057] of the specification), “In an example embodiment, in an instance in which the first security protocol is RACF and the second security protocol is used, the standard db2 exit routine is modified to identify the user identity information and in such an instance in which the user identity information is provided, RACF is used to authenticate the process”. It is noted that (“RACF” and “Db2” are registered trademarks of IBM.). In addition, the default Db2 exit routine in IBM documentation discloses if you install the RACF access control module, RACF can perform Db2 authorization checking for SQL statements, commands, and utilities. You can also choose to provide your own routine for the Db2 access control authorization exit point. This document describes how to implement only the supplied RACF access control module and DB2® access control authorization exit). Therefore, there is no inventive step regarding the “RACF” and “Db2” standards as recited in the specification of the instant application.
In regards to claim 2, the combination of Geusz and Aupperle in view of Guski teaches the system of Claim 1, wherein the second security protocol is used in an instance in which the ACEE is not provided.
However, Guski teaches wherein the second security protocol is used in an instance in which the ACEE is not provided (Guski, Para. 0070, a client end-user 300 invokes an HTTP or Web services request 310 to perform a transaction 303 within the initial authentication component 305 of the transaction processing environment 301. The user's credentials, e.g., user ID and password, are verified in the local user registry 306, and if accepted, the user 300 is identified and authenticated by the initial authentication component 305 (step 500). In one example, identification and authentication could be accomplished over a 128-bit SSL connection between the user 300 and the initial authentication component 305).
Geusz, Aupperle and Guski are all considered to be analogous to the claim invention because they are in the same field of monitoring one or more security protocol used during an authentication process. Therefore, it would have been obvious to someone ordinary skill in the art before the effective filling date of the claimed invention to have modified Geusz and Aupperle to incorporate the teachings of Guski to include wherein the second security protocol is used in an instance in which the ACEE is not provided (Guski, Para. 0070). Doing so would aid to provide a way for identity-differentiating information, including but not restricted to that which a customer might add to the identity information that is propagated by z/OS Identity Propagation (ID Prop), to be specifically indicated as being a necessary part of the hashable portion of the propagated identity information, and for this "hashable indicator information" to be propagated along with the rest of the identity information. The advantage and novelty of the invention is that this "hashable indicator information" is thus available to receivers of propagated identities, such as CICS and IMS, so that their cache keys (previously described) can be correctly constructed dynamically according to the particular customer dictated situation (Guski, Para. 0007).
In regards to claim 3, the combination of Geusz and Aupperle in view of Guski teaches the system of Claim 1, wherein one or more actions to allow the authentication to use the first security protocol comprises updating a process code of a standard exite routine to identify the account to allow for the first security protocol to operate (Geusz, Col. 20, Lines 58-67, and Col. 21, Lines 1-14, the protocol management server accesses first authentication data that demonstrates that the particular user has been authenticated using a first authentication protocol (204). In some implementations, the protocol management server determines the first authentication data from the management database that indicates the protocol utilized to connect the client device to the protocol management server. The protocol management server can use an identifier of a client device, such as a name or user ID, to retrieve one or more keys from the device profiles in the management data database. The one or more keys can be used to determine whether any TGTs exist for the client device. The TGT indicates that the client devices has been approved or authenticated to communicate with the management server and the key distribution center (KDC). If no TGTs exist, the protocol management server can pre-authorize and negotiate the TGTs for one or more services corresponding to one or more users with the KDC. The management server can receive a TGT for the client device from the KDC to store in the authentication tokens. The TGT includes a session key indicated by the KDC, an expiration date, and the client device's IP address. Thus, the particular user now has the first authentication data to communicate with the protocol management server and the KDC).
In regards to claim 4, the combination of Geusz and Aupperle in view of Guski teaches the system of Claim 2, wherein at least one of the actions comprises creating the user identity information based on the process (Aupperle, Para. 0051, the passticket generation process also considers the target host application), and location-related wireless data provided by a GPS receiver module of an end-point device of the user (Geuz, Col. 26, Lines 61-65, a GPS (Global Positioning System) receiver module 370 may provide additional navigation- and location-related wireless data to the mobile computing device 350, which may be used as appropriate by applications running on the mobile computing device 350). Therefore, it would have been obvious to someone ordinary skill in the art before the effective filling date of the claimed invention to have modified Geusz and Guski to incorporate the teachings of Aupperle to include wherein at least one of the actions comprises creating the user identity information based on the process (Aupperle, Para. 0051), and location-related wireless data provided by a GPS receiver module of an end-point device of the user (Col. 26, Lines 61-65). Doing so would aid to grant user access to protected legacy host applications by leveraging security tokens created when establishing secure Web-based communications. Users can then seamlessly and securely access a plurality of modern Web applications and/or legacy host applications, within a single user session, without having to identify themselves multiple times. This secure access is provided transparently to the user, who no longer has to maintain separate passwords and user IDs for accessing legacy host applications (Aupperle, Para. 0042).
In regards to claim 5, the combination of Geusz and Aupperle in view of Guski teaches the system of Claim 4, wherein the user identity information comprises access level to one or more process relating to a user (Aupperle, Para. 0063, this passticket represents the access privileges for the user identified by the subject field of the digital certificate transmitted from the TN3270 server).
Therefore, it would have been obvious to someone ordinary skill in the art before the effective filling date of the claimed invention to have modified Geusz and Guski to incorporate the teachings of Aupperle to include wherein the user identity information comprises access level to one or more process relating to a user (Aupperle, Para. 0063). Doing so would aid to grant user access to protected legacy host applications by leveraging security tokens created when establishing secure Web-based communications. Users can then seamlessly and securely access a plurality of modern Web applications and/or legacy host applications, within a single user session, without having to identify themselves multiple times. This secure access is provided transparently to the user, who no longer has to maintain separate passwords and user IDs for accessing legacy host applications (Aupperle, Para. 0042).
In regards to claim 6, the combination of Geusz and Aupperle in view of Guski teaches the system of Claim 1, wherein the at least one processing device is configured to actively monitor the security protocol used for the authentication (Geusz, Col. 1, Lines 19-25, a management server can provide a layer of abstraction to manage authentication for a user to access many resources, regardless of the specific authentication protocol required by the individual resources. As a result, the management server can automatically obtain and maintain authenticated sessions on behalf of a user across multiple authentication protocols).
In regards to claim 7, the combination of Geusz and Aupperle in view of Guski teaches the system of Claim 1, wherein the at least one processing device is configured to cause a transmission of a notification in an instance in which the second security protocol is used in the authentication (Aupperle, Para. 0048, the client's digital certificate is required when establishing the SSL connection) and (Aupperle, Para. 0063, this passticket represents the access privileges for the user identified by the subject field of the digital certificate transmitted from the TN3270 server). Therefore, it would have been obvious to someone ordinary skill in the art before the effective filling date of the claimed invention to have modified Geusz and Guski to incorporate the teachings of Aupperle to include the system of Claim 1, wherein the at least one processing device is configured to cause a transmission of a notification in an instance in which the second security protocol is used in the authentication (Aupperle, Para. 0048) and (Aupperle, Para. 0063). Doing so would aid to grant user access to protected legacy host applications by leveraging security tokens created when establishing secure Web-based communications. Users can then seamlessly and securely access a plurality of modern Web applications and/or legacy host applications, within a single user session, without having to identify themselves multiple times. This secure access is provided transparently to the user, who no longer has to maintain separate passwords and user IDs for accessing legacy host applications (Aupperle, Para. 0042).
In regards to claim 8, the computer program product claim 8 relates to the system claim 1. Therefore, claim 8 is rejected for the same reason as claim 1.
In regards to claim 9, the computer program product claim 9 relates to the system claim 2. Therefore, claim 9 is rejected for the same reason as claim 2.
In regards to claim 10, the computer program product claim 10 relates to the system claim 3. Therefore, claim 10 is rejected for the same reason as claim 3.
In regards to claim 11, the computer program product claim 11 relates to the system claim 4. Therefore, claim 11 is rejected for the same reason as claim 4.
In regards to claim 12, the computer program product claim 12 relates to the system claim 5. Therefore, claim 12 is rejected for the same reason as claim 5.
In regards to claim 13, the computer program product claim 13 relates to the system claim 6. Therefore, claim 13 is rejected for the same reason as claim 6.
In regards to claim 14, the computer program product claim 14 relates to the system claim 7. Therefore, claim 14 is rejected for the same reason as claim 7.
In regards to claim 15, the computer-implemented method claim 15 relates to the system claim 1 and computer program product claim 8. Therefore, claim 15 is rejected for the same reason as claims 1 and 8.
In regards to claim 16, the computer-implemented method claim 16 relates to the system claim 2 and computer program product claim 9. Therefore, claim 16 is rejected for the same reason as claims 2 and 9.
In regards to claim 17, the computer-implemented method claim 17 relates to the system claim 3 and computer program product claim 10. Therefore, claim 17 is rejected for the same reason as claims 3 and 10.
In regards to claim 18, the combination of Geusz and Aupperle in view of Guski teaches the method of Claim 16, wherein at least one of the actions comprises creating the user identity information based on the process (Aupperle, Para. 0051, the passticket generation process also considers the target host application), and location-related wireless data provided by a GPS receiver module of an end-point device of the user (Geuz, Col. 26, Lines 61-65, a GPS (Global Positioning System) receiver module 370 may provide additional navigation- and location-related wireless data to the mobile computing device 350, which may be used as appropriate by applications running on the mobile computing device 350). Therefore, it would have been obvious to someone ordinary skill in the art before the effective filling date of the claimed invention to have modified Geusz and Guski to incorporate the teachings of Aupperle to include wherein at least one of the actions comprises creating the user identity information based on the process (Aupperle, Para. 0051), and location-related wireless data provided by a GPS receiver module of an end-point device of the user (Geuz, Col. 26, Lines 61-65), wherein the user identity information comprises access level to one or more process relating to a user (Aupperle, Para. 0063). Doing so would aid to grant user access to protected legacy host applications by leveraging security tokens created when establishing secure Web-based communications. Users can then seamlessly and securely access a plurality of modern Web applications and/or legacy host applications, within a single user session, without having to identify themselves multiple times. This secure access is provided transparently to the user, who no longer has to maintain separate passwords and user IDs for accessing legacy host applications (Aupperle, Para. 0042).
In regards to claim 19, the computer-implemented method claim 19 relates to the system claim 6 and computer program product claim 13. Therefore, claim 19 is rejected for the same reason as claims 6 and 13.
In regards to claim 20, the computer-implemented method claim 20 relates to the system claim 4 and computer program product claim 14. Therefore, claim 19 is rejected for the same reason as claims 7 and 14The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. See PTOL-892.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to GITA FARAMARZI whose telephone number is (571)272-0248. The examiner can normally be reached Monday- Friday 9:00 am- 6:00 pm.
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, Jorge L. Ortiz-Criado can be reached at (571)272-7624. 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.
/GITA FARAMARZI/Examiner, Art Unit 2496
/JORGE L ORTIZ CRIADO/Supervisory Patent Examiner, Art Unit 2496