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 .
This Office Action is in response to the Amendment filed on 7/2/2025.
In instant Amendment, claims 21, 22, and 38-40 have been amended; claims 21 and 38-40 are independent claims. Claims 21-40 have been examined and are pending. This Action is made Final.
Response to Arguments
Applicant's arguments filed on 7/2/2025 with respect to the 35 U.S.C. 101 rejection have been fully considered but they are not persuasive.
Applicant Argues: Applicant, despite disagreeing with the rejection, has herein amended independent claim 21 such that the rejection of claim 21 under 35 U.S.C. 101 is traversed. Namely, Applicant has herein amended claim 21 to recite features of "receive, by a customer device from a service provider of a service provider network, a password policy including a set of password rules defined by the service provider based on a respective set of regular expressions," "receive, by the customer device, a request to set a password on the customer device," and "support, by the customer device, management and enforcement of the set of password rules in the password policy by: evaluating, by the customer device using the password policy, whether the password satisfies the set of password rules in the password policy; and determining, by the customer device based on the evaluation of the password using the password policy, whether to set the password on the customer device." Applicant submits that amended claim 21 satisfies the requirements of 35 U.S.C. 101 and is patentable thereunder.
Thus, Applicant's independent claim 21 satisfies the requirements of 35 U.S.C. 101 and is patentable thereunder. Additionally, at least for the reasons discussed above, Applicant's independent claim 38 also satisfies the requirements of 35 U.S.C. 101 and is patentable thereunder. Furthermore, since all of the dependent claims that depend from the independent claim include all the features of the independent claim from which they ultimately depend, each such dependent claim also satisfies the requirements of 35 U.S.C. 101 and is patentable thereunder.
Therefore, Applicant respectfully requests that the rejection be withdrawn
Examiner’s Response: The examiner respectfully disagrees.
Applicant's arguments fail to comply with 37 CFR 1.111(b) because they amount to a general allegation that the claims define a patentable invention without specifically pointing out how the language of the claims patentably distinguishes over the subject matter eligibility analysis.
The examiner respectfully notes that limitations of “support management and enforcement of the set of password rules in the password policy by: evaluating, using the password policy whether the password satisfies the set of password rules in the password policy; and determining, based on evaluation of the password using the password policy, whether to set the password on the customer device.” under its broadest reasonable interpretation, covers performance of the limitation in the mind but for the recitation of generic computer components. That is, other than reciting processor and memory (i.e., customer device/service provider) nothing in these claim element(s) precludes the step(s) from practically being performed in the mind. For example, in context of these claims, the limitations noted above encompasses steps that a user can manually perform with the aid of pencil/paper. If a claim limitation, under its broadest reasonable interpretation, covers performance of the limitation in the mind but for the recitation of generic computer components, then it falls within the “mental processes” grouping of abstract ideas. Accordingly, the claim recites an abstract idea.
Further, as noted in the rejection below the judicial exception is not integrated into a practical application. Limitations that are not indicative of integration into a practical application include: (1) Adding the words “apply it” (or an equivalent) with the judicial exception, or mere instructions to implement an abstract idea on a computer, or merely uses a computer as a tool to perform an abstract idea (MPEP 2106.05(f)), (2) Adding insignificant extra-solution activity to the judicial exception (MPEP 2106.05(g)), (3) Generally linking the use of the judicial exception to a particular technological environment or field of use (MPEP 2106.05(h)). In particular, the claim only recites additional elements of i.e., processor and memory (i.e., customer device/service provider). These elements in the steps are recited at a high-level of generality (i.e., generic computer) such that it amounts no more than mere instructions to apply the exception using a generic computer components. In addition, of the steps of “receiving...” merely represents insignificant extra-solution activity that does not add significantly more to the abstract idea to render the claimed invention patent-eligible. See MPEP § 2106.05(g). Accordingly, these additional element(s) do not integrate the abstract idea into a practical application because it does not impose any meaningful limits on practicing the abstract idea. The claim is directed to an abstract idea.
The claim does not include additional elements that are sufficient to amount to significantly more than the judicial exception. As discussed above with respect to integration of the abstract idea into a practical application, the additional elements of i.e., processor and memory amounts to no more than mere instructions to apply the exception using a generic computer component. Mere instructions to apply an exception using a generic computer component cannot provide an inventive concept. In addition, for the additional steps of “receiving...” are noted to be well understood, routing, and conventional, see MPEP 2106.05(d)(II) - receiving or transmitting data over a network, e.g., using the Internet to gather data.
These claims are not patent eligible.
Applicant's arguments filed on 7/2/2025 with respect to the 35 U.S.C. 102/103 rejection have been fully considered but they are not persuasive.
With respect to Claim 21
Applicant Argues: First, Applicant submits that the rejection of independent claim 21 in view of McCulligh is deficient. Namely, the cited portions of McCulligh fail to disclose or suggest at least the feature of “a password policy including a set of password rules defined...based on a respective set of regular expressions.” The cited portions of McCulligh are devoid of any disclosure or suggestion of regular expressions, much less use of regular expressions to define password rules. Thus, the cited portions of McCulligh fail to disclose or suggest at least the feature of “a password policy including a set of password rules defined... based on a respective set of regular expressions.”
Examiner’s Response: The examiner respectfully disagrees. The examiner respectfully notes that FIG. 4 depicts “a password policy including a set of password rules defined”, see FIG. 4 – Rules for new passwords. The examiner further notes FIG. 4 depicts under Rules for new passwords “Must be at least 8 characters long, Must contain an upper case character, Must contain a lower case character, Must contain a number character, Must not repeat any character more than length/2 times” which are a respective set of regular expressions used to define the password rule. The examiner respectfully notes the metes and bounds of the claim have been met; therefore, the examiner finds this argument not persuasive.
Applicant Argues: Second, Applicant, despite disagreeing with the rejection and in the interest of furthering prosecution of the application, has herein amended independent claim 21 to recite features of [...] Applicant submits that the cited portions of McCulligh fail to disclose or suggest the features of "receive, by a customer device from a service provider of a service provider network, a password policy including a set of password rules defined by the service provider based on a respective set of regular expressions," "receive, by the customer device, a request to set a password on the customer device," and "support, by the customer device, management and enforcement of the set of password rules in the password policy by: evaluating, by the customer device using the password policy, whether the password satisfies the set of password rules in the password policy; and determining, by the customer device based on the evaluation of the password using the password policy, whether to set the password on the customer device."
Thus, Applicant's independent claim 21 is allowable under 35 U.S.C. 102 over McCulligh. Additionally, Applicant's independent claim 38 recites relevant features similar to the features of Applicant's independent claim 21 and, thus, at least for the same reasons, also is allowable under 35 U.S.C. 102 over McCulligh. Furthermore, since all of the dependent claims that depend from the independent claim include all the features of the independent claim from which they ultimately depend, each such dependent claim also is allowable under 35 U.S.C. 102 over McCulligh.
Therefore, Applicant respectfully requests that the rejection be withdrawn.
Examiner’s Response: The examiner respectfully disagrees.
Applicant's arguments do not comply with 37 CFR 1.111(c) because they do not clearly point out the patentable novelty which he or she thinks the claims present in view of the state of the art disclosed by the references cited or the objections made. Further, they do not show how the amendments avoid such references or objections.
The examiner respectfully notes that McCulligh discloses the aforementioned features of
receive, by a customer device from a service provider of a service provider network, a password policy including a set of password rules defined by the service provider based on a respective set of regular expressions (FIG. 1 and FIG. 4 – Rules For New Passwords and col. 3, lines 20-43 - When used in a computer network system, the apparatus 10 may be operatively coupled to a manager server which has software serving as a policy certificate generator 26... The policy certificate generator 26 generates certificates that contain password generation rule data that is used by a plurality of nodes such as a node containing apparatus 10. In this way, a centralized security mechanism is provided to ensure that all nodes or specific class of users use the same password generation rule data and col. 7, lines 23-33);
receive, by the customer device, a request to set a password on the customer device (FIG. 1 and FIG. 4 and col. 5, lines 51-55 - As shown in block 60, the system provides a graphic user interface or other suitable interface for a user to indicate that a change in password is desired); and
support by the customer device, management and enforcement of the set of password rules in the password policy (col. 6, lines 4-24) by:
evaluating, by the customer device, using the password policy whether the password satisfies the set of password rules in the password policy(FIG. 1 and FIG. 4 and col. 6, lines 4-24 - As shown in block 70, the system receives the password data character change information 38 input through the input device on a per character basis, or other suitable character length basis as selected through the policy certificate. As shown in block 72, the system continuously evaluates each configured rule on a per character change basis prior to receiving complete notification data and generates the appropriate status feedback data (e.g., password rule status data) for the notification device. The appropriate password rule status feedback data is dynamically generated on a continuous basis. As shown in block 74, the system determines whether the password rule status data is equal to confirmation data for all rules, meaning that all selected rules have been met by the character password data that has been entered by the user. If the status feedback password rule data indicates that all rules have been met, the system will accept the changed password and generates the accepted password change data as shown in block 76. However, if the password rule status data indicates that non-confirmation data still exists, the system returns to block 70 awaiting the receipt of new character data); and
determining, by the customer device based on evaluation of the password using the password policy, whether to set the password on the customer device (FIG. 1 and FIG. 4 and col. 6, lines 4-24 - As shown in block 70, the system receives the password data character change information 38 input through the input device on a per character basis, or other suitable character length basis as selected through the policy certificate. As shown in block 72, the system continuously evaluates each configured rule on a per character change basis prior to receiving complete notification data and generates the appropriate status feedback data (e.g., password rule status data) for the notification device. The appropriate password rule status feedback data is dynamically generated on a continuous basis. As shown in block 74, the system determines whether the password rule status data is equal to confirmation data for all rules, meaning that all selected rules have been met by the character password data that has been entered by the user. If the status feedback password rule data indicates that all rules have been met, the system will accept the changed password and generates the accepted password change data as shown in block 76. However, if the password rule status data indicates that non-confirmation data still exists, the system returns to block 70 awaiting the receipt of new character data).
As noted from the citations above, McCulligh describes all nodes or specific class of users use the same password generation rule data receive the password policy/rules based on a regular set of expressions, see, FIG. 1 and FIG. 4 – Rules For New Passwords and col. 3, lines 20-43, thus reads on the first limitation of the claim. Further, McCulligh describes the system provides a graphic user interface or other suitable interface for a user to indicate that a change in password is desired, see, col. 5, lines 51-55, thus reads on the second limitation of the claim. Finally, McCulligh describes the system receives the password data character change information 38 input through the input device on a per character basis, or other suitable character length basis as selected through the policy certificate. As shown in block 72, the system continuously evaluates each configured rule on a per character change basis prior to receiving complete notification data and generates the appropriate status feedback data (e.g., password rule status data) for the notification device. The appropriate password rule status feedback data is dynamically generated on a continuous basis. As shown in block 74, the system determines whether the password rule status data is equal to confirmation data for all rules, meaning that all selected rules have been met by the character password data that has been entered by the user. If the status feedback password rule data indicates that all rules have been met, the system will accept the changed password and generates the accepted password change data as shown in block 76. However, if the password rule status data indicates that non-confirmation data still exists, the system returns to block 70 awaiting the receipt of new character data, see, FIG. 4 and col. 6, lines 4-24, thus reading on the last three limitations of the claim. The examiner respectfully notes the metes and bounds of the claim have been met; therefore, the examiner finds this argument not persuasive.
With respect to Claim 39 and 40
Applicant Argues: First, Applicant submits that the rejection of independent claim 39 in view of McCulligh is deficient. Namely, the cited portions of McCulligh fail to disclose or suggest at least the feature of "wherein the password policy includes a set of password rules defined...using a respective set of regular expressions." The cited portions of McCulligh are devoid of any disclosure or suggestion of regular expressions, much less use of regular expressions to define password rules. Thus, the cited portions of McCulligh fail to disclose or suggest at least the feature of "wherein the password policy includes a set of password rules defined... using a respective set of regular expressions."
Examiner’s Response: The examiner notes similar rationale is noted per the reasoning set forth in Claim 21 above. Therefore, the examiner finds this argument not persuasive.
Applicant Argues: Second, Applicant, despite disagreeing with the rejection and in the interest of furthering prosecution of the application, has herein amended independent claim 39 to recite features of [...] Applicant submits that the cited portions of McCulligh fail to disclose or suggest the features of "receive, by a device management element of a service provider network, a password policy represented using a device management data model, wherein the password policy includes a set of password rules defined by a service provider of the service provider network using a respective set of regular expressions" and "send, by the device management element toward a customer device based on a device management protocol associated with the device management data model, the password policy for supporting management and enforcement of the set of password rules in the password policy at the customer device." Thus, Applicant's independent claim 39 is allowable under 35 U.S.C. 102 over McCulligh. Additionally, Applicant's independent claim 40 recites relevant features similar to the features of Applicant's independent claim 39 and, thus, at least for the same reasons, also is allowable under 35 U.S.C. 102 over McCulligh.
Therefore, Applicant respectfully requests that the rejection be withdrawn.
Examiner’s Response: The examiner respectfully disagrees.
Applicant's arguments do not comply with 37 CFR 1.111(c) because they do not clearly point out the patentable novelty which he or she thinks the claims present in view of the state of the art disclosed by the references cited or the objections made. Further, they do not show how the amendments avoid such references or objections.
The examiner respectfully notes that McCulligh discloses the aforementioned features of
receive, by a device management element of a service provider network, a password policy represented using a device management data model, wherein the password policy includes a set of password rules defined by a service provider of the service provider network using a respective set of regular expressions (FIG. 1 and FIG. 4 – Rules For New Passwords and col. 3, lines 20-43 - When used in a computer network system, the apparatus 10 may be operatively coupled to a manager server which has software serving as a policy certificate generator 26... The policy certificate generator 26 generates certificates that contain password generation rule data that is used by a plurality of nodes such as a node containing apparatus 10. In this way, a centralized security mechanism is provided to ensure that all nodes or specific class of users use the same password generation rule data and col. 7, lines 23-33); and
send, by the device management element toward a customer device based on a device management protocol associated with the device management data model, the password policy for supporting management and enforcement of the set of password rules in the policy at the customer device(FIG. 1 and FIG. 4 – Rules For New Passwords and col. 3, lines 20-43 - When used in a computer network system, the apparatus 10 may be operatively coupled to a manager server which has software serving as a policy certificate generator 26... The policy certificate generator 26 generates certificates that contain password generation rule data that is used by a plurality of nodes such as a node containing apparatus 10. In this way, a centralized security mechanism is provided to ensure that all nodes or specific class of users use the same password generation rule data and col. 7, lines 23-33).
As noted from the citations above, McCulligh describes a manger server has a policy certificate generator, see, FIG. 1 and FIG. 4 and col. 3, lines 20-43, thus reads on the first limitation of the claim. Further, McCulligh describes all nodes or specific class of users use the same password generation rule data receive the password policy/rules based on a regular set of expressions, see, FIG. 1 and FIG. 4 – Rules For New Passwords and col. 3, lines 20-43, thus reads on the second limitation of the claim. The examiner respectfully notes the metes and bounds of the claim have been met; therefore, the examiner finds this argument not persuasive.
Applicant Argues: Applicant submits that these grounds of rejection apply only to dependent claims and are predicated on the validity of the rejection of Applicant's independent claim 21 under 35 U.S.C. 102 in view of McCulligh. Applicant submits that, since such rejection has been overcome, as described hereinabove, and there is no argument put forth by the Office Action that the additional references supply that which is missing from McCulligh to render Applicant's independent claim 21 unpatentable, these grounds of rejection cannot be maintained.
Therefore, Applicant respectfully requests that the rejections be withdrawn.
Examiner’s Response: The examiner disagrees for the reasons set forth above. Therefore, the examiner finds this argument not persuasive.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claim(s) 21-38 is/are rejected under 35 U.S.C. 101 because the claimed invention is directed to abstract idea without significantly more.
The MPEP indicates that claims that recite matter that falls within the following enumerated groupings of abstract ideas should be treated as reciting abstract ideas (emphasis added):
(a) Mathematical concepts—mathematical relationships, mathematical formulas or equations, mathematical calculations;
(b) Certain methods of organizing human activity—fundamental economic principles or practices (including hedging, insurance, mitigating risk); commercial or legal interactions (including agreements in the form of contracts; legal obligations; advertising, marketing or sales activities or behaviors; business relations); managing personal behavior or relationships or interactions between people (including social activities, teaching, and following rules or instructions); and
(c) Mental processes—concepts performed in the human mind (including an observation, evaluation, judgment, opinion).
For example, regarding claim 21 and representative claim 38; these claim(s) recite the abstract idea of determination/evaluation of a password policy or general maters related to password policies thus would fall under the enumerated grouping of mental processes.
For example, claim 21 and representative claim 38, recite concepts performed in the human mind (including an observation, evaluation, judgment, opinion, more specifically the claims recite:
support
evaluating,
determining,
The examiner respectfully notes, as drafted, the limitations above, under its broadest reasonable interpretation, covers performance of the limitation in the mind but for the recitation of generic computer components. That is, other than reciting processor and memory nothing in these claim element(s) precludes the step(s) from practically being performed in the mind. For example, in context of these claims, the limitations noted above (i.e., supportpassword policy whether the password satisfies the set of password rules in the password policy; and determining...based on based on evaluation of the password using the password policy, whether to set the password on the customer device) encompasses steps that a user can manually perform with the aid of pencil/paper. If a claim limitation, under its broadest reasonable interpretation, covers performance of the limitation in the mind but for the recitation of generic computer components, then it falls within the “mental processes” grouping of abstract ideas. Accordingly, the claim recites an abstract idea.
This judicial exception is not integrated into a practical application. Limitations that are not indicative of integration into a practical application include: (1) Adding the words “apply it” (or an equivalent) with the judicial exception, or mere instructions to implement an abstract idea on a computer, or merely uses a computer as a tool to perform an abstract idea (MPEP 2106.05(f)), (2) Adding insignificant extra-solution activity to the judicial exception (MPEP 2106.05(g)), (3) Generally linking the use of the judicial exception to a particular technological environment or field of use (MPEP 2106.05(h)). In particular, the claim only recites additional elements of i.e., processor and memory (i.e., customer device/service provider). These elements in the steps are recited at a high-level of generality (i.e., generic computer) such that it amounts no more than mere instructions to apply the exception using a generic computer components. In addition, of the steps of “receiving...” merely represents insignificant extra-solution activity that does not add significantly more to the abstract idea to render the claimed invention patent-eligible. See MPEP § 2106.05(g). Accordingly, these additional element(s) do not integrate the abstract idea into a practical application because it does not impose any meaningful limits on practicing the abstract idea. The claim is directed to an abstract idea.
The claim does not include additional elements that are sufficient to amount to significantly more than the judicial exception. As discussed above with respect to integration of the abstract idea into a practical application, the additional elements of i.e., processor and memory amounts to no more than mere instructions to apply the exception using a generic computer component. Mere instructions to apply an exception using a generic computer component cannot provide an inventive concept. In addition, for the additional steps of “receiving...” are noted to be well understood, routing, and conventional, see MPEP 2106.05(d)(II) - receiving or transmitting data over a network, e.g., using the Internet to gather data.
These claims are not patent eligible.
Regarding Claims 22-37; claims 22-37 further defines the abstract idea that is present in their respective independent claims and hence are abstract for at least the reasons presented above w/ respect to mental processes (i.e., claims 22-37 encompass additional steps that a user can manually perform with the aid of pencil/paper). These dependent claims do not include any additional elements (i.e. server/client (Claim 22), protocols (Claims 23 and 23), management element (Claims 25 and 26.), and/or interface (Claims 30-32) that integrate the abstract idea into a practical application as these additional elements are recited at a high level of generality such that it amounts no more than mere instructions to apply the exception using a generic computer component. Even in combination, these additional elements do not integrate the abstract idea into a practical application and do no not amount to significantly more than the abstract idea itself. Thus, these aforementioned claims are not patent-eligible.
Claim Rejections - 35 USC § 102
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 the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
Claim(s) 21, 22, 30, 31, and 33-40 is/are rejected under 35 U.S.C. 102(a)(2) as being anticipated by McCulligh (US 6,643,784 B1).
Regarding Claim 21;
McCulligh discloses an apparatus (FIG. 1), comprising:
at least one processor (FIG. 1 and col. 3, lines 1-19 and col. 7, lines 1-8 – ...processing unit...); and
at least one memory including instructions which, when executed by the at least one processor (FIG. 1 and col. 3, lines 1-19 and col. 7, lines 1-8 – ...storage medium...), cause the apparatus at least to:
receive, by a customer device from a service provider of a service provider network, a password policy including a set of password rules defined by the service provider based on a respective set of regular expressions (FIG. 1 and FIG. 4 – Rules For New Passwords and col. 3, lines 20-43 - When used in a computer network system, the apparatus 10 may be operatively coupled to a manager server which has software serving as a policy certificate generator 26... The policy certificate generator 26 generates certificates that contain password generation rule data that is used by a plurality of nodes such as a node containing apparatus 10. In this way, a centralized security mechanism is provided to ensure that all nodes or specific class of users use the same password generation rule data and col. 7, lines 23-33);
receive, by the customer device, a request to set a password on the customer device (FIG. 1 and FIG. 4 and col. 5, lines 51-55 - As shown in block 60, the system provides a graphic user interface or other suitable interface for a user to indicate that a change in password is desired); and
support by the customer device, management and enforcement of the set of password rules in the password policy (col. 6, lines 4-24) by:
evaluating, by the customer device, using the password policy whether the password satisfies the set of password rules in the password policy(FIG. 1 and FIG. 4 and col. 6, lines 4-24 - As shown in block 70, the system receives the password data character change information 38 input through the input device on a per character basis, or other suitable character length basis as selected through the policy certificate. As shown in block 72, the system continuously evaluates each configured rule on a per character change basis prior to receiving complete notification data and generates the appropriate status feedback data (e.g., password rule status data) for the notification device. The appropriate password rule status feedback data is dynamically generated on a continuous basis. As shown in block 74, the system determines whether the password rule status data is equal to confirmation data for all rules, meaning that all selected rules have been met by the character password data that has been entered by the user. If the status feedback password rule data indicates that all rules have been met, the system will accept the changed password and generates the accepted password change data as shown in block 76. However, if the password rule status data indicates that non-confirmation data still exists, the system returns to block 70 awaiting the receipt of new character data); and
determining, by the customer device based on evaluation of the password using the password policy, whether to set the password on the customer device (FIG. 1 and FIG. 4 and col. 6, lines 4-24 - As shown in block 70, the system receives the password data character change information 38 input through the input device on a per character basis, or other suitable character length basis as selected through the policy certificate. As shown in block 72, the system continuously evaluates each configured rule on a per character change basis prior to receiving complete notification data and generates the appropriate status feedback data (e.g., password rule status data) for the notification device. The appropriate password rule status feedback data is dynamically generated on a continuous basis. As shown in block 74, the system determines whether the password rule status data is equal to confirmation data for all rules, meaning that all selected rules have been met by the character password data that has been entered by the user. If the status feedback password rule data indicates that all rules have been met, the system will accept the changed password and generates the accepted password change data as shown in block 76. However, if the password rule status data indicates that non-confirmation data still exists, the system returns to block 70 awaiting the receipt of new character data).
Regarding Claim 22;
McCulligh discloses the apparatus to Claim 21.
McCulligh further discloses wherein the password policy is received from a device of the service provider network (col. 3, lines 20-43 - When used in a computer network system, the apparatus 10 may be operatively coupled to a manager server which has software serving as a policy certificate generator 26. The manager server with policy certificate generator 26 may generate public key certificates, such as those that are compliant with ITU-T Recommendation X.500standards as known in the art, or any other suitable certificate mechanism where a trusted authority signs information through a cryptographic mechanism for use by a relying party. In this embodiment, the policy certificate generator 26 and the apparatus 10 use public key cryptography techniques, as known in the art, to verify policy certificate data. One example of a policy certificate generator may be found for example in co-pending patent application entitled, "A Computer Network Security System and Method Having Unilateral Enforceable Security Policy Provision", Patent Application No. 08/986,457, filed Dec. 8, 1998, assigned to instant assignee, and hereby incorporated by reference as though fully stated herein. The policy certificate generator 26 generates certificates that contain password generation rule data that is used by a plurality of nodes such as a node containing apparatus 10. In this way, a centralized security mechanism is provided to ensure that all nodes or specific class of users use the same password generation rule data).
Regarding Claim 30;
McCulligh discloses the apparatus to Claim 21.
McCulligh further discloses wherein the request to set the password on the customer device is received via a device management interface (FIG. 1 and FIG. 4 and col. 3, lines 14-19 – A password character input device 24 allows a user or other software application to input password data characters to the apparatus 10. The password character input device 24 may be a keyboard, voice recognition system, software application, or any other suitable input mechanism)
Regarding Claim 31;
McCulligh discloses the apparatus to Claim 30.
McCulligh further discloses wherein the device management interface is a customer-facing device management interface (FIG. 1 and FIG. 4 and col. 3, lines 14-19 – A password character input device 24 allows a user or other software application to input password data characters to the apparatus 10. The password character input device 24 may be a keyboard, voice recognition system, software application, or any other suitable input mechanism).
Regarding Claim 33;
McCulligh discloses the apparatus to Claim 21.
McCulligh further wherein the evaluation of the password using the password policy is based on a regular expression evaluation engine (FIG. 1 – Per Character Change PE Evaluator and FIG. 4 and col. 5, lines 9-27 and col. 6, lines 4-24 - As shown in block 70, the system receives the password data character change information 38 input through the input device on a per character basis, or other suitable character length basis as selected through the policy certificate. As shown in block 72, the system continuously evaluates each configured rule on a per character change basis prior to receiving complete notification data and generates the appropriate status feedback data (e.g., password rule status data) for the notification device. The appropriate password rule status feedback data is dynamically generated on a continuous basis. As shown in block 74, the system determines whether the password rule status data is equal to confirmation data for all rules, meaning that all selected rules have been met by the character password data that has been entered by the user. If the status feedback password rule data indicates that all rules have been met, the system will accept the changed password and generates the accepted password change data as shown in block 76. However, if the password rule status data indicates that non-confirmation data still exists, the system returns to block 70 awaiting the receipt of new character data and col. 7, lines 23-34 - FIG. 4 pictorially represents a display screen showing password generation rule data 20 and corresponding password rule status data 42 represented as "X"'s and check marks. As shown, a display device outputs the data for view by a user. The user enters the password character data and the processor outputs the password rule status data as the user enters the data. As shown, the user in this example improperly entered characters that indicated that the password rules were not met since the entered password does not contain a numeric character as indicated by the "X"'s. Those rules that have been met have a check mark by them).
Regarding Claim 34;
McCulligh discloses the apparatus to Claim 21.
McCulligh further discloses wherein the evaluation of the password using the password policy includes evaluation of the password with respect to each of the regular expressions to determine whether the password satisfies each of the password rules of the password policy (FIG. 1 and FIG. 4 and col. 6, lines 4-24 - As shown in block 70, the system receives the password data character change information 38 input through the input device on a per character basis, or other suitable character length basis as selected through the policy certificate. As shown in block 72, the system continuously evaluates each configured rule on a per character change basis prior to receiving complete notification data and generates the appropriate status feedback data (e.g., password rule status data) for the notification device. The appropriate password rule status feedback data is dynamically generated on a continuous basis. As shown in block 74, the system determines whether the password rule status data is equal to confirmation data for all rules, meaning that all selected rules have been met by the character password data that has been entered by the user. If the status feedback password rule data indicates that all rules have been met, the system will accept the changed password and generates the accepted password change data as shown in block 76. However, if the password rule status data indicates that non-confirmation data still exists, the system returns to block 70 awaiting the receipt of new character data and col. 7, lines 23-34 - FIG. 4 pictorially represents a display screen showing password generation rule data 20 and corresponding password rule status data 42 represented as "X"'s and check marks. As shown, a display device outputs the data for view by a user. The user enters the password character data and the processor outputs the password rule status data as the user enters the data. As shown, the user in this example improperly entered characters that indicated that the password rules were not met since the entered password does not contain a numeric character as indicated by the "X"'s. Those rules that have been met have a check mark by them).
Regarding Claim 35;
McCulligh discloses the apparatus to Claim 21.
McCulligh further discloses wherein the instructions, when executed by the at least one processor, cause the apparatus at least to: permit the password to be set on the customer device based on a determination that the password satisfies the password policy (FIG. 1 and FIG. 4 and col. 6, lines 4-24 - As shown in block 70, the system receives the password data character change information 38 input through the input device on a per character basis, or other suitable character length basis as selected through the policy certificate. As shown in block 72, the system continuously evaluates each configured rule on a per character change basis prior to receiving complete notification data and generates the appropriate status feedback data (e.g., password rule status data) for the notification device. The appropriate password rule status feedback data is dynamically generated on a continuous basis. As shown in block 74, the system determines whether the password rule status data is equal to confirmation data for all rules, meaning that all selected rules have been met by the character password data that has been entered by the user. If the status feedback password rule data indicates that all rules have been met, the system will accept the changed password and generates the accepted password change data as shown in block 76. However, if the password rule status data indicates that non-confirmation data still exists, the system returns to block 70 awaiting the receipt of new character data and col. 7, lines 23-34 - FIG. 4 pictorially represents a display screen showing password generation rule data 20 and corresponding password rule status data 42 represented as "X"'s and check marks. As shown, a display device outputs the data for view by a user. The user enters the password character data and the processor outputs the password rule status data as the user enters the data. As shown, the user in this example improperly entered characters that indicated that the password rules were not met since the entered password does not contain a numeric character as indicated by the "X"'s. Those rules that have been met have a check mark by them).
Regarding Claim 36;
McCulligh discloses the apparatus to Claim 21.
McCulligh further discloses wherein the instructions, when executed by the at least one processor, cause the apparatus at least to: prevent the password from being set on the customer device based on a determination that the password fails to satisfy the password policy (FIG. 1 and FIG. 4 and col. 6, lines 4-24 - As shown in block 70, the system receives the password data character change information 38 input through the input device on a per character basis, or other suitable character length basis as selected through the policy certificate. As shown in block 72, the system continuously evaluates each configured rule on a per character change basis prior to receiving complete notification data and generates the appropriate status feedback data (e.g., password rule status data) for the notification device. The appropriate password rule status feedback data is dynamically generated on a continuous basis. As shown in block 74, the system determines whether the password rule status data is equal to confirmation data for all rules, meaning that all selected rules have been met by the character password data that has been entered by the user. If the status feedback password rule data indicates that all rules have been met, the system will accept the changed password and generates the accepted password change data as shown in block 76. However, if the password rule status data indicates that non-confirmation data still exists, the system returns to block 70 awaiting the receipt of new character data and col. 7, lines 23-34 - FIG. 4 pictorially represents a display screen showing password generation rule data 20 and corresponding password rule status data 42 represented as "X"'s and check marks. As shown, a display device outputs the data for view by a user. The user enters the password character data and the processor outputs the password rule status data as the user enters the data. As shown, the user in this example improperly entered characters that indicated that the password rules were not met since the entered password does not contain a numeric character as indicated by the "X"'s. Those rules that have been met have a check mark by them).
Regarding Claim 37;
McCulligh discloses the apparatus to Claim 21.
McCulligh further discloses wherein the customer device is a customer gateway device or a customer premises equipment device (col. 3, lines 1-40 - FIG. 1 shows one example of the apparatus for facilitating password generation 10 incorporated into a computer network system. It will be recognized that the apparatus 10 may be utilized in a standalone unit if desired or any suitable system. The apparatus 10 may be a suitably programmed computer or any other suitable hardware/software combination if desired... When used in a computer network system, the apparatus 10 may be operatively coupled to a manager server which has software serving as a policy certificate generator 26. The manager server with policy certificate generator 26 may generate public key certificates, such as those that are compliant with ITU-T Recommendation X.500standards as known in the art, or any other suitable certificate mechanism where a trusted authority signs information through a cryptographic mechanism for use by a relying party... the policy certificate generator 26 generates certificates that contain password generation rule data that is used by a plurality of nodes such as a node containing apparatus 10. In this way, a centralized security mechanism is provided to ensure that all nodes or specific class of users use the same password generation rule data).
Regarding Claim(s) 38; claim(s) 38 is/are directed to a/an method associated with the apparatus claimed in claim(s) 21. Claim(s) 38 is/are similar in scope to claim(s) 21, and is/are therefore rejected under similar rationale.
Regarding Claim 39;
McCulligh discloses an apparatus (FIG. 1), comprising:
at least one processor (FIG. 1 and col. 3, lines 1-19 and col. 7, lines 1-8 – ...processing unit...); and
at least one memory including instructions which, when executed by the at least one processor (FIG. 1 and col. 3, lines 1-19 and col. 7, lines 1-8 – ...storage medium...), cause the apparatus at least to:
receive, by a device management element of a service provider network, a password policy represented using a device management data model, wherein the password policy includes a set of password rules defined by a service provider of the service provider network using a respective set of regular expressions (FIG. 1 and FIG. 4 – Rules For New Passwords and col. 3, lines 20-43 - When used in a computer network system, the apparatus 10 may be operatively coupled to a manager server which has software serving as a policy certificate generator 26... The policy certificate generator 26 generates certificates that contain password generation rule data that is used by a plurality of nodes such as a node containing apparatus 10. In this way, a centralized security mechanism is provided to ensure that all nodes or specific class of users use the same password generation rule data and col. 7, lines 23-33);; and
send, by the device management element toward a customer device based on a device management protocol associated with the device management data model, the password policy for supporting management and enforcement of the set of password rules in the policy at the customer device(FIG. 1 and FIG. 4 – Rules For New Passwords and col. 3, lines 20-43 - When used in a computer network system, the apparatus 10 may be operatively coupled to a manager server which has software serving as a policy certificate generator 26... The policy certificate generator 26 generates certificates that contain password generation rule data that is used by a plurality of nodes such as a node containing apparatus 10. In this way, a centralized security mechanism is provided to ensure that all nodes or specific class of users use the same password generation rule data and col. 7, lines 23-33).
Regarding Claim(s) 40; claim(s) 40 is/are directed to a/an method associated with the apparatus claimed in claim(s) 39. Claim(s) 40 is/are similar in scope to claim(s) 30, and is/are therefore rejected under similar rationale.
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 p