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 .
Election/Restrictions
NO restrictions warranted at applicant’s initial time of filing for patent.
Priority
Applicant claims domestic priority under 35 USC 371 as a NATIONAL STAGE APPLICATION of PCT/BG2022/000006 filed on 05/30/2022.
Applicant also claims foreign priority under 35 USC 119[b] to Bulgarian application # 113519, filed on 04/07/2022.
Applicant’s certified foreign priority document was filed with the office on 10/07/2024.
Information Disclosure Statement
NO information disclosure statements (IDS) were submitted at applicant’s initial time of filing for patent.
Drawings
Applicant’s drawings filed on 10/07/2024 have been inspected and are in compliance with MPEP 608.02.
Specification
The title of the invention is not descriptive. A new title is required that is clearly indicative of the invention to which the claims are directed.
The following title is suggested: Method of dynamic password element authentication.
The abstract of the disclosure is objected to because the abstract includes numbers [i.e.… /54/,.. /57/…], which makes the abstract appear informal.
A corrected abstract of the disclosure is required and must be presented on a separate sheet, apart from any other text. See MPEP § 608.01(b).
The abstract of the disclosure is objected to because the abstract includes the phrase “..and/or…”, which makes the abstract difficult to understand – based on that it is unclear as to which elements [i.e. key strokes, cursor movements (keyloggers)…etc.] further limit the abstract.
A corrected abstract of the disclosure is required and must be presented on a separate sheet, apart from any other text. See MPEP § 608.01(b).
Claim Objections
NO claim objections warranted at applicant’s initial time of filing for patent.
Claim Interpretation – 35 USC 112th f
It is in the examiner’s opinion that claim[s] 30 – 45 do not invoke means for or step plus functional claim language under the meaning of the statute.
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.
Claim[s] 30 is 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. The claims recite the phrase “..and/or….,” which is unclear to one of ordinary skilled in the art. Based it is not clear as to which elements further limit the claim language and which elements are merely for “intend/field of use…..” For example, in claim 30, lines 2 – 5 and line 44, “…..a library with n elements distributed according to their distinctive property in q sets (e.g. numbers, letters, special characters, colours, textures, arrows, zodiac and other signs, logos, hieroglyphs, images, photos, other two-dimensional and/or three-dimensional objects), the passcode being received on the user interface,…..”
Appropriate action required.
***For examination purpose, the examiner will assume that such identified claim limitation is in the alternative, meaning that one element singly found in the prior art will meet the burden of anticipation or obviousness, respectively.
Claim[s] 30 is 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. It unclear from claim # 1, line 45, whether or not the claim language of: “…(if generated and manifested)…,” further limits the claim language and whether or not the claim language is an “intend/(field of) use …..”
Appropriate action required.
Claim[s] 37 is 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. It unclear from claim # 37, line 3, whether or not the claim language of: “…(so-called indicator (implicit numeric sign))…,” further limits the claim language and whether or not the claim language is an “intend/(field of) use …..”
Appropriate action required.
Claim[s] 45 is 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. It unclear from claim # 45, lines 3 - 4, whether or not the claim language of: “…(another user with whom the user requiring passcode reset has a “shared secret”)…,” further limits the claim language and whether or not the claim language is an “intend/(field of) use…..”
Appropriate action required.
Claim[s] 45 is 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. It unclear from claim # 45, lines 1 - 2, whether or not the claim language of: “… if a user fails to remember the secret combination…,” further limits the claim language and whether or not the claim language is an “intend/(field of) use…..”
Appropriate action required.
Double Patenting
NO rejections warranted at applicant’s initial time of filing for patent.
Claim Rejections - 35 USC § 101
NO rejections warranted at applicant’s initial time of filing for patent.
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)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
Claim(s) 30 – 39, 41, 44 is/are rejected under 35 U.S.C. 102(a)(2) as being taught by Finnan et al. [US PGPUB # 2023/0057862].
As per claim # 30. Finnan does teach the method for authentication [Finnan, paragraph: 0101, lines 1 – 6, Embodiments in which the device presenting the dynamic interface is separate from the authentication database, the incorporation of an additional communication between the authentication database and presentation device may be used to introduce a zero-knowledge protocol] comprising:
user passcode creation comprising:
receiving a selected passcode sequence comprising k elements (E₁, E₂,…. Eₖ) from a library with n elements distributed according to their distinctive property in q sets (e.g. numbers, letters, special characters, colours, textures, arrows, zodiac and other signs, logos, hieroglyphs, images, photos, other two-dimensional and/or three- dimensional objects), the passcode being received on the user interface, wherein each element Eᵢ (iE[1;k]) is assigned a system interpretation value VEᵢ (iE[1;k]), by which the element is identified, and each property set is assigned a set identifier, wherein the set identifier of the set to which the element Eᵢ belongs is stored as a property pattern PEᵢ with the passcode sequence for passcode validation [Finnan, Figure # 72 and paragraph: 0072, When a user of the system chooses to create a new passcode, a method 2700 depicted in FIG. 27 will be executed. At block 2705 of method 2700, each virtual key is associated with a plurality of properties. At any point during passcode creation, a user can choose to cancel the process at block 2710, thereby clearing any previously selected properties and beginning the process anew. Upon the selection of one of the keys at block 2715, the system, at block 2720, records the interpretation value of all properties associated with the selected key for the present position in the passcode. This process is repeated until passcode entry is complete at block 2725, at which time the system executes the property dispersion algorithm block 2735 shown in FIGS. 14a-21, after which the resulting configuration is displayed, and the user is prompted to confirm the previously entered passcode.
Where further of Finnan, paragraph: 0090, lines 14 – 21, If the passcode creation is complete at block 360a, then at block 370a, the system saves the interpretation values as a valid passcode for future use during passcode entry. The system also stores the property set identifier from which each property is chosen during passcode creation as the property pattern at block 380a.
Where further of Finnan, at Figure # 5, and paragraph: 0069, The process by which the passcode is created for this embodiment is described by method 500 in FIG. 5. The system, at block 510 of method 500, either manifests the interface or the interface is built as a physical component of a device to be used for passcode creation. At any point during passcode creation, a user can choose to cancel the process at block 520, thereby clearing any previously selected properties and beginning the process anew. Upon the selection of one of the keys at block 530, the system, at block 540, manifests a virtual key for each of the properties associated with the selected key. When one of the newly manifested virtual keys is selected at block 550, the system, at block 560, records the interpretation value of the property associated with the selected key for the present position in the passcode. This process is repeated until passcode creation is complete at block 570, at which time the system saves the interpretation values as a valid passcode for future use during passcode entry at block 580.
Where further of Finnan, at Figure # 32, and paragraph: 0116, lines 1 – 8, FIG. 33 illustrates a method 3300 by which a passcode can be converted into a traditional ASCII password during passcode entry and validation for use with current systems. This example method 3300 is demonstrated using the standard ASCII printable character values 3200 provided for reference in FIG. 32 along with the property set configuration 3100 presented in FIG. 31.];
encrypting the sequence of system interpretation values (VE₁, VE₂,….., VEₖ) of elements (E₁, E₂,…. Eₖ) from the selected passcode [Finnan, paragraph: 0089, Password encryption can be implemented by identifying all possible passcode combinations based on the properties of each virtual key selected for each position in the entered passcode. Each of these combinations could then be encrypted and compared to the encrypted value of the stored passcode, which was previously encrypted at the time it was created. A successful match for any of the combinations indicates a valid passcode.]; and
storing the encrypted sequence Hₛ of system interpretation values (VE₁, VE₂,……VEₖ) of elements (E₁, E₂,…. E) from the selected passcode and their property pattern (PE₁, PE₂,……,PEₖ) in a user database [Finnan, paragraph: 0069, lines 15 – 18, This process is repeated until passcode creation is complete at block 570, at which time the system saves the interpretation values as a valid passcode for future use during passcode entry at block 580.], and
user passcode authentication comprising:
accessing a user information database comprising the encrypted sequence Hₛ of system interpretation values (VE₁, VE₂, VEₖ) of elements (E₁, E₂, Eₖ) from the selected passcode and their property pattern (PE₁, PE₂, PEₖ) [Finnan, Finnan, paragraph: 0089, Password encryption can be implemented by identifying all possible passcode combinations based on the properties of each virtual key selected for each position in the entered passcode. Each of these combinations could then be encrypted and compared to the encrypted value of the stored passcode, which was previously encrypted at the time it was created];
generating and manifesting random arrangements of elements into selection fields Fj (jE[1;v]) on a login screen, one above the other (in separate layers) or next to each other, among which are also the elements (E₁, E₂, Eₖ) from the selected passcode [Finnan, Figure # 7, and paragraph: 0054, lines 1 – 10, when passcode entry is used, the properties associated with the virtual keys are shuffled as depicted by a method 700 of FIG. 7. This process begins with the arrangement depicted in FIG. 1 and can result in the arrangement depicted in FIG. 4. At block 705 of method 700, a member from each property set is associated with each virtual key in a generally random manner, for which an example is depicted in a method 1100 of FIG. 11, resulting in the arrangement depicted in FIG. 1. ];
receiving a selection of selection fields and identifying the elements in them that matter for the authentication using the stored property pattern [Finnan, paragraph: 0102, lines 7 – 13, Further embodiments may be created in which individuals, groups, and/or points of access may utilize different property sets or interfaces through which passcodes are entered. It is also conceivable to utilize different property sets or interfaces on a contextual basis, dependent upon criteria such as the information being accessed, or transaction being performed.];
encrypting the received sequence of system interpretive values of the identified elements [Finnan, paragraph: 0089, Password encryption can be implemented by identifying all possible passcode combinations based on the properties of each virtual key selected for each position in the entered passcode. Each of these combinations could then be encrypted and compared to the encrypted value of the stored passcode, which was previously encrypted at the time it was created. A successful match for any of the combinations indicates a valid passcode.];
comparing the encrypted sequence Hₛ with the stored Hₛ and granting access if there is a match (Hx=Hₛ) and denial of access if there is no match (Hx/Hₛ) [Finnan, paragraph: 0089, Password encryption can be implemented by identifying all possible passcode combinations based on the properties of each virtual key selected for each position in the entered passcode. Each of these combinations could then be encrypted and compared to the encrypted value of the stored passcode, which was previously encrypted at the time it was created. A successful match for any of the combinations indicates a valid passcode.], characterized with that:
at least one of the n elements in the library has shape pointing direction and could serve as pointer (implicit directional sign) [Finnan, Figure # 28, component # 2810];
when receiving a selected passcode sequence, for each element Eᵢ from the passcode sequence (E₁, E₂,…..,Eₖ) a rule REᵢ is received, where at least one rule REᵢ is configured by the User through a logic model, which uses the given element as a starting point, each rule REᵢ is assigned a systemic interpretation value VREᵢ, through which the rule is identified, and rules Ru, not bound to any element, can also be received, where each rule Ru is assigned a systemic interpretation value VRu, and conditions and a way of submitting instructions Ic can also be received, where each instruction Ic is assigned a systemic interpretation value Vic [Finnan, Figure # 32, and paragraph: 0116, lines 1 – 8, FIG. 33 illustrates a method 3300 by which a passcode can be converted into a traditional ASCII password during passcode entry and validation for use with current systems. This example method 3300 is demonstrated using the standard ASCII printable character values 3200 provided for reference in FIG. 32 [i.e. applicant’s….logic model…where a rule is assigned an interpretation value] along with the property set configuration 3100 presented in FIG. 31.];
the systemic interpretation values of the rules and the conditions and the way of submitting the V be generated and manifested on the login screen, amending element(s) of the selected passcode sequence and/or rule(s) for the current authentication session [Finnan, paragraph: 0102, lines 7 – 13, Further embodiments may be created in which individuals, groups, and/or points of access may utilize different property sets or interfaces through which passcodes are entered. It is also conceivable to utilize different property sets or interfaces on a contextual basis, dependent upon criteria such as the information being accessed, or transaction being performed.];
when identifying the elements that matter for the authentication, the instructions (if generated and manifested) and the stored rules are also used [Finnan, paragraph: 0102, lines 7 – 13, Further embodiments may be created in which individuals, groups, and/or points of access may utilize different property sets or interfaces through which passcodes are entered. It is also conceivable to utilize different property sets or interfaces on a contextual basis, dependent upon criteria such as the information being accessed, or transaction being performed. ].
As per claim 31. Finnan does teach the method according to claim 30, characterized with that the logic model determines a logical connection (relation) set on an algebraic, geometric, associative or custom principle, using operations such as addition (+), subtraction (I), multiplication (x), division (÷), displacement (Ax), conjunction (A), disjunction (V), negation (-), exclusionary disjunction (V), implication (=), double implication () [Finnan, Figure # 32, and paragraph: 0116, lines 1 – 8, FIG. 33 illustrates a method 3300 by which a passcode can be converted into a traditional ASCII password during passcode entry and validation for use with current systems. This example method 3300 is demonstrated using the standard ASCII printable character values 3200 provided for reference in FIG. 32 along with the property set configuration 3100 presented in FIG. 31.].
As per claim 32. Finnan does teach the method according to claim 30, characterized with that in each selection field there must be an element from a property set suitable for configuring a logic model and at least one rule REᵢ is configured through a logic model using this element [Finnan, Figure # 32, and paragraph: 0116, lines 1 – 8, FIG. 33 illustrates a method 3300 by which a passcode can be converted into a traditional ASCII password during passcode entry and validation for use with current systems. This example method 3300 is demonstrated using the standard ASCII printable character values 3200 provided for reference in FIG. 32 [i.e. applicant’s….selection field….an element from a property set suitable for configuring a logic model…and at least one rule is configured…a logic model using the element] along with the property set configuration 3100 presented in FIG. 31.].
As per claim 33. Finnan does teach the method according to claim 30, characterized with that for all elements of the passcode sequence a common rule is configured by a common logic model [Finnan, Figure # 32, and paragraph: 0116, lines 1 – 8, FIG. 33 illustrates a method 3300 by which a passcode can be converted into a traditional ASCII [i.e. applicant’s…all elements of the passcode sequence a common rule……by a common logic model] password during passcode entry and validation for use with current systems. This example method 3300 is demonstrated using the standard ASCII printable character values 3200 provided for reference in FIG. 32 along with the property set configuration 3100 presented in FIG. 31.].
As per claim 34. Finnan does teach the method according to claim 30, characterized with that the logic model can be changed cyclically, randomly [Finnan, Figure # 7, and paragraph: 0054, lines 1 – 10, when passcode entry is used, the properties associated with the virtual keys are shuffled as depicted by a method 700 of FIG. 7. This process begins with the arrangement depicted in FIG. 1 and can result in the arrangement depicted in FIG. 4. At block 705 of method 700, a member from each property set is associated with each virtual key in a generally random manner, for which an example is depicted in a method 1100 of FIG. 11, resulting in the arrangement depicted in FIG. 1.], periodically, on a geographical or event basis.
As per claim 35. Finnan does teach the method according to claim 30, characterized with that at least one rule Ru requires field selection to be performed in a certain way [Finnan, Figure # 32, and paragraph: 0116, lines 1 – 8, FIG. 33 illustrates a method 3300 by which a passcode can be converted into a traditional ASCII [i.e. applicant’s…at least one rule requires field selection to be performed in a certain way] password during passcode entry and validation for use with current systems. This example method 3300 is demonstrated using the standard ASCII printable character values 3200 provided for reference in FIG. 32 along with the property set configuration 3100 presented in FIG. 31.].
As per claim 36. Finnan does teach the method according to claim 30, characterized with that at least one rule Ru requires misleading manipulations and the number (m) of these manipulations is indicated by one of the other elements (so-called indicator (implicit numeric sign)) in the selection field in which a secret element is located [Finnan, paragraph: 0101, line 12 – 26, In an exemplary embodiment, this communication would include transmission of a value, or set of values, derived from the system interpretation values comprising a password. Once received by the presentation device, a cryptographic transformation is performed on the value which is secret to the presentation device, thereby producing a result which is completely unknown to the authentication database. This result is then input as the password component into a defined zero-knowledge protocol between the authentication database and presentation device for final verification.].
As per claim 37. Finnan does teach the method according to claim 30, characterized with that at least one rule Ru requires misleading manipulations and the position (p) of these manipulations is indicated by one of the other elements (so-called indicator (implicit numeric sign)) in the selection field in which a secret element is located [Finnan, paragraph: 0101, line 12 – 26, In an exemplary embodiment, this communication would include transmission of a value, or set of values, derived from the system interpretation values comprising a password. Once received by the presentation device, a cryptographic transformation is performed on the value which is secret to the presentation device, thereby producing a result which is completely unknown to the authentication database. This result is then input as the password component into a defined zero-knowledge protocol between the authentication database and presentation device for final verification.].
As per claim 38. Finnan does teach the method according to claim 30, characterized with that the instructions are manifested by the secret elements [Finnan, paragraph: 0101, line 12 – 26, In an exemplary embodiment, this communication would include transmission of a value, or set of values, derived from the system interpretation values comprising a password. Once received by the presentation device, a cryptographic transformation is performed on the value which is secret to the presentation device, thereby producing a result which is completely unknown to the authentication database. This result is then input as the password component into a defined zero-knowledge protocol between the authentication database and presentation device for final verification.].
As per claim 39. Finnan does teach the method according to claim 30, characterized with that the instructions are manifested by any of the other elements in a selection field in which a secret element is located [Finnan, paragraph: 0101, line 12 – 26, In an exemplary embodiment, this communication would include transmission of a value, or set of values, derived from the system interpretation values comprising a password. Once received by the presentation device, a cryptographic transformation is performed on the value which is secret to the presentation device, thereby producing a result which is completely unknown to the authentication database.].
As per claim 41. Finnan does teach the method according to claim 32, characterized with that for the property set "arrows" at least one rule REᵢ requires to follow the direction of the arrow in the same selection field, where element Eᵢ is located [Finnan, Figure # 28, component # 2810].
As per claim 44. Finnan does teach the method according to claim 30 or a combination thereof, characterized with that it grants access to the content of an encrypted message or file through the identification choice based on the secret combination of the recipient and the shared secret combination agreed with the sender [Finnan, paragraph: 0101, line 12 – 26, In an exemplary embodiment, this communication would include transmission of a value, or set of values, derived from the system interpretation values comprising a password. Once received by the presentation device, a cryptographic transformation is performed on the value which is secret to the presentation device, thereby producing a result which is completely unknown to the authentication database. This result is then input as the password component into a defined zero-knowledge protocol between the authentication database and presentation device for final verification.].
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or non-obviousness.
Claim(s) 40, 42, 43 is/are rejected under 35 U.S.C. 103 as being unpatentable over Finnan et al. [US PGPUB # 2023/0057862] in view of Mooney [US PGPUB # 2019/0236258]
As per claim 40. Finnan who does teach what is taught in the rejection of claim # 30 above.
Finnan does not clearly teach the method according to claim 30, characterized with that some of the elements on the login screen can move (rotate) in a given authentication session.
However, Mooney does teach the method according to claim 30, characterized with that some of the elements on the login screen can move (rotate) in a given authentication session [paragraph: 0025, This disclosure relates generally to entering a passcode into a device to unlock/access the device. The layout or arrangement of the soft keys/buttons on a device is dynamically changed. In this manner, a user entering a passcode will always have to enter it in a different pattern by pressing buttons in different locations, thereby preventing someone from learning the passcode by simply watching or recording a user entering the passcode.].
It would have been obvious to one of ordinary skilled in the art before the effective filing date of the claimed invention to combine the teachings of Finnan and Mooney in order for securing creating a passcode of Finnan to include a randomly generated passcode user interfaces of Mooney. This would allow for the a user authentication password to be generated at time of authentication of user by passcode before access. See paragraph: 0031 of Mooney.
***The examiner also points to paragraph: 0049 of Mooney regarding this claim limitation.
As per claim 42. Finnan as modified does teach the method according to claim 35, characterized with that the field selection has to be performed by swiping, partial marking, side marking, or holding (pressing for a number of seconds) [Mooney, paragraph: 0046, lines 8 – 16, In response to an input to the user device, e.g., a button press or voice command, the user device can generate a user interface that is displayed via the display device 111. The user interface can include a plurality of user interface elements, e.g. a keyboard or number pad with a plurality of keys. The user interface can facilitate the input of an authentication credential to unlock the user device.].
As per claim 43. Finnan as modified does teach the method according to claim 30 or a combination thereof, characterized with that it grants access to the content of an encrypted message or file through the identification choice based on the secret combination of the recipient [Mooney, paragraph: 0046, lines 1 – 8, As an example, the computer 101 can comprise a user device such as a mobile device. The user device can implement a “lock” feature, whereby one or more functions of the user device are restricted. For example, access to applications or files on the user device can be restricted from access until an authentication credential is input to the user device, thereby “unlocking” the user device.].
Claim(s) 45 is/are rejected under 35 U.S.C. 103 as being unpatentable over Finnan et al. [US PGPUB # 2023/0057862] in view of Sun et al. [US PGPUB # 2019/0165944]
As per claim 45. Finnan who does teach what is taught in the rejection of claim # 44 above.
Finnan does not clearly teach the method according to claim 44, characterized with that if a user fails to remember the secret combination, he is given the opportunity to enter a new secret combination, which however, in order to become active, must be confirmed by a guarantor (another user with whom the user requiring passcode reset has a "shared secret") who has to enter the "shared secret" within a certain period of time after the request.
However, Sun does teach the method according to claim 44, characterized with that if a user fails to remember the secret combination, he is given the opportunity to enter a new secret combination, which however, in order to become active, must be confirmed by a guarantor (another user with whom the user requiring passcode reset has a "shared secret") who has to enter the "shared secret" within a certain period of time after the request [Figure # 1, and paragraph: 0012, lines 1 – 20, In step 314, when the passcode does not meet the quality threshold one or more data protection rules can be applied, as shown in step 316. Data protection rules can include setting a timer for a predetermined period of time, during which no passcodes can be entered (lockout), setting an additional timer if/when the number of unauthorized passcodes received exceeds a second, higher threshold number and/or erasing all or a portion of the data on the device. Continuing with step 314, when the passcode meets the quality threshold the data protection policy provides for an alternate authentication path in step 318 to allow further attempts, or to initiate additional authentication data protection rule options to the data protection policy. In each case, the authentication may incorporate additional constraints, according to best practices in the security industries. In one embodiment the secondary data protection rule allows for an unauthorized attempt threshold to be increased, or reset to zero. In another example embodiment, the device can initiate communication with a device module or service provider to initiate a passcode reset [i.e. applicant’s….must be confirmed by a guarantor].].
It would have been obvious to one of ordinary skilled in the art before the effective filing date of the claimed invention to combine the teachings of Finnan as modified and Sun in order for securing creating a passcode of Finnan as modified to include authenticating the requesting user before creating a secure passcode of Sun. This would allow for multifactor authentication implementation to prove the user is authorized for creation of a passcode for use. See paragraph: 0027 of Sun.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Anders et al., who does teach authenticating both objective and subjective credentials. A user selects objective credentials, such as a password, and enters subjective credentials, such as a subjective description of the user's emotional response to a subjective challenge, such as a musical recording or image. The system identifies other content likely to elicit a similar emotional response from the same user. When the user later attempts to log onto a secured system, the user must enter the objective credentials and then describe the user's emotional response to a second subjective challenge that is likely to elicit an emotional response similar to that invoked by the first subjective challenge.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to DANT SHAIFER - HARRIMAN whose telephone number is (571)272-7910. The examiner can normally be reached M - F: 9am to 5pm.
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, Kambiz Zand can be reached at 571- 272- 3811. 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.
/DANT B SHAIFER HARRIMAN/ Primary Examiner, Art Unit 2434