DETAILED ACTION
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 Application No. 18/554,538 filed on 10/09/2023.
As per the Preliminary Amendment filed on 10/09/2023, claims 1-29 are canceled; claims 30-49 have been added. Claims 30-49 have been examined and are pending in this application.
Priority
Acknowledgment is made of Applicant’s claim for foreign priority under 35 U.S.C. 119 (a)-(d) to parent Application No. CN202210998425.0, filed on 08/19/2022.
Information Disclosure Statement
The information disclosure statement (IDS), submitted on 06/14/2024 and 11/08/2023 are in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statements are being considered by the examiner.
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.
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 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.
Claim(s) 30, 34-35, 37, 40, 44-45, 47, and 49 are rejected under 35 U.S.C. 103 as being unpatentable over Cronkright et al. (US 2024/0205218; Hereinafter “Cronkright”) in view of Ma et al. (US 2023/0388782; Hereinafter “Ma”).
Regarding claim 30, Cronkright teaches a method, comprising: establishing a communication connection with a mobile phone;
displaying a first login interface of a target website, wherein the first login interface comprises a mobile number input box and a verification code input box (Cronkright: Fig. 10C-2, Para. [0160], where the ST server 104 is operable to control the secure webpage to display another login page represented by GUI 1012A. In some implementations, as shown by FIG. 10C-2, the GUI 1012B is another login page that includes a selectable “request one-time code” GUI element 2000 where the user can request the one-time code by SMS or voice call. Verification input box = element 1014, mobile number input box = element 2000);
displaying, in response to a first operation into the mobile number input box, a first option on the first login interface, wherein the first option is configured to obtain a mobile number of the mobile phone (Cronkright: Fig. 10C-2, Para. [0160], In some implementations, as shown by FIG. 10C-2, the GUI 1012B is another login page that includes a selectable “request one-time code” GUI element 2000 where the user can request the one-time code by SMS or voice call. [element 2000 includes selectable option to use SMS authorization via phone number]);
obtaining, in response to a second operation into the first option, a first mobile number of the mobile phone from the mobile phone (Cronkright: Fig. 10C-2, Second operation may include selecting the “Phone Number” input box 2000 of Fig. 10C-2 via gesture or touch on the mobile phone interface and then entering the mobile number into the selected input box on the mobile phone);
triggering the mobile phone to receive verification information corresponding to the target website based on the first mobile number (Cronkright: Para. [0160], In some implementations, as shown by FIG. 10C-2, the GUI 1012B is another login page that includes a selectable “request one-time code” GUI element 2000 where the user can request the one-time code by SMS or voice call. Para. [0162], At step 918, the ST server 104 receives the OTC request and the MCD information transmitted by the registered user's mobile communication device 102A and compares the received MCD information to MCD information stored in the user's account data 502. When, at step 920, the ST server 104 finds a match between the received MCD information and the MCD information stored in the user's account data 502, the process 900 advances to step 924 where the ST server 104 is operable to generate a one-time code and to transmit the generated OTC to the matching mobile communication device 102A. For example, the ST server transmits the generated OTC to the registered user's mobile communication device 102A that transmitted the OTC request.).
obtaining the verification information from the mobile phone (Cronkright: Para. [0160], Para. [0162], For example, the ST server transmits the generated OTC to the registered user's mobile communication device 102A that transmitted the OTC request.);
filling the verification code input box with the verification information (Cronkright: Para. [0163], At step 928, the process 900 advances to step 928 where the registered user enters the OTC 1108 displayed on the display screen 230 of the registered user's mobile communication device 102A into the OTC GUI field 1104 of the login GUI 1012 displayed by the ST server 104 on the registered user's computer 102B (e.g., FIG. 10D) and then selects the “login” GUI element 1016.);
Cronkright does not explicitly teach filling the mobile number input box with the first mobile number; and logging in to the target website based on the first mobile number and the verification information.
In an analogous art, Ma teaches obtaining, in response to a second operation into the first option, a first mobile number of the mobile phone from the mobile phone (Ma: Para. [0269], The login interface displays a mobile phone number input box and a password input box. A user can enter a mobile phone number and a password into the mobile phone number input box and the password input box to log in. )
filling the mobile number input box with the first mobile number (Ma: Para. [0269], When detecting an operation of tapping a “Registration” control by the user, the mobile phone displays an interface shown in FIG. 3B(c). The interface includes a mobile phone number input box, and the user may enter a mobile phone number in the input box, for example, 185 xxxx xxxx.);
triggering the mobile phone to receive verification information corresponding to the target website based on the first mobile number (Ma: Para. [0269], The foregoing first operation may be an operation of tapping a “Next” control in the interface shown in FIG. 3B(c); or the first operation may be an operation of another type, for example, a voice instruction used for instructing to register with MeeTime. This is not limited in this embodiment of this application. Para. [0270]-[0272], S102: The mobile phone sends a registration application to a MeeTime cloud service. The registration application may carry the mobile phone number of the user, for example, the mobile phone number 185 xxxx xxxx in FIG. 3B(c). S103: The mobile phone receives an SMS verification code sent by the MeeTime cloud service.);
obtaining the verification information from the mobile phone (Ma: Para. [0273], After receiving the registration application sent by the mobile phone, the MeeTime cloud service sends the SMS verification code to the mobile phone number carried in the registration application. For example, if the mobile phone number carried in the registration application is 185 xxxx xxxx, the MeeTime cloud service sends the SMS verification code, for example, 123456, to the mobile phone number 185 xxxx xxxx.);
filling the verification code input box with the verification information (Ma: Para. [0273], After receiving the verification code, the mobile phone may enter the verification code into a verification code input box.); and
logging in to the target website based on the first mobile number and the verification information (Ma: Para. [0273], When detecting an operation on a “Complete” control, the mobile phone sends the entered SMS verification code to the MeeTime cloud service. Alternatively, the “Complete” control in FIG. 3B(d) may not be displayed. For example, after it is detected that entering of the verification code is completed (for example, the verification code is six digits, and it is detected that the user has entered six digits to confirm input completion), the entered SMS verification code is sent to the MeeTime cloud service by default. Para. [0274]-[0276], S104: The mobile phone sends the SMS verification code to the MeeTime cloud service. S105: The MeeTime cloud service attempts to verify the SMS verification code. the MeeTime cloud server may attempt to verify the SMS verification code, for example, determine whether the received SMS verification code is consistent with the sent SMS verification code. If yes, the verification succeeds; otherwise, the verification fails.).
It would have been obvious to a person having ordinary skill in the art, before the effective filing date of the claimed invention, to combine the teachings of Ma with the system and method of Cronkright to include filling the mobile number input box with the first mobile number; and logging in to the target website based on the first mobile number and the verification information because this functionality improves security by ensuring successful verification of the code prior to login or registration (Ma: Para. [0276]).
Regarding claim 34, Cronkright, in combination with Ma, teaches the method of claim 30, wherein the first option comprises at least part of the first mobile number (Ma: Fig. 3B(c), [portion of mobile phone number is obfuscated by “xxxx”] (Ma: Para. [0269], When detecting an operation of tapping a “Registration” control by the user, the mobile phone displays an interface shown in FIG. 3B(c). The interface includes a mobile phone number input box, and the user may enter a mobile phone number in the input box, for example, 185 xxxx xxxx.)).
Regarding claim 35, Cronkright, in combination with Ma, teaches the method of claim 30, wherein the first login interface comprises a second option and triggering the mobile phone to receive verification information corresponding to the target website based on the first mobile number comprises sending the first mobile number to a server of the target website in response to a selection operation for the second option, to cause the server to send verification information to the mobile phone according to the first mobile number (Cronkright: Fig. 10C-2, Para. [0160], In some implementations, as shown by FIG. 10C-2, the GUI 1012B is another login page that includes a selectable “request one-time code” GUI element 2000 where the user can request the one-time code by SMS or voice call. [element 2000 includes multiple selectable options to receive a one-time code], Para. [0162], At step 918, the ST server 104 receives the OTC request and the MCD information transmitted by the registered user's mobile communication device 102A and compares the received MCD information to MCD information stored in the user's account data 502. When, at step 920, the ST server 104 finds a match between the received MCD information and the MCD information stored in the user's account data 502, the process 900 advances to step 924 where the ST server 104 is operable to generate a one-time code and to transmit the generated OTC to the matching mobile communication device 102A. For example, the ST server transmits the generated OTC to the registered user's mobile communication device 102A that transmitted the OTC request. Ma: Para. [0269], The foregoing first operation may be an operation of tapping a “Next” control in the interface shown in FIG. 3B(c); or the first operation may be an operation of another type, for example, a voice instruction used for instructing to register with MeeTime. This is not limited in this embodiment of this application. Para. [0270]-[0272], S102: The mobile phone sends a registration application to a MeeTime cloud service. The registration application may carry the mobile phone number of the user, for example, the mobile phone number 185 xxxx xxxx in FIG. 3B(c). S103: The mobile phone receives an SMS verification code sent by the MeeTime cloud service. Para. [0273], After receiving the registration application sent by the mobile phone, the MeeTime cloud service sends the SMS verification code to the mobile phone number carried in the registration application. For example, if the mobile phone number carried in the registration application is 185 xxxx xxxx, the MeeTime cloud service sends the SMS verification code, for example, 123456, to the mobile phone number 185 xxxx xxxx.).
Regarding claim 37, Cronkright, in combination with Ma, teaches the method of claim 30, further comprising displaying a preset waiting interface before filling the mobile number input box with the first mobile number or before filling the verification code input box with the verification information (Ma: Fig. 3B(d), Para. [0273], For example, if the mobile phone number carried in the registration application is 185 xxxx xxxx, the MeeTime cloud service sends the SMS verification code, for example, 123456, to the mobile phone number 185 xxxx xxxx. After receiving the verification code, the mobile phone may enter the verification code into a verification code input box. As shown in FIG. 3B(d), the user enters the SMS verification code “123456”. When detecting an operation on a “Complete” control, the mobile phone sends the entered SMS verification code to the MeeTime cloud service. [Fig #B(d) illustrates an interface displayed when waiting to input the verification code after it is transmitted or resent]).
Regarding Claim 40, Claim 40 is rejected under the same rational as claim 30.
Regarding Claim 44, Claim 44 is rejected under the same rational as claim 34.
Regarding Claim 45, Claim 45 is rejected under the same rational as claim 35.
Regarding Claim 47, Claim 47 is rejected under the same rational as claim 37.
Regarding Claim 49, Claim 49 is rejected under the same rational as claim 30.
Claim(s) 31, 36, 41, and 46 are rejected under 35 U.S.C. 103 as being unpatentable over Cronkright et al. (US 2024/0205218; Hereinafter “Cronkright”) in view of Ma et al. (US 2023/0388782; Hereinafter “Ma”) in view of Everson et al. (US 2020/0100108; Hereinafter “Everson”).
Regarding claim 31, Cronkright, in combination with Ma, teaches the method of claim 30. Cronkright, in combination with Ma, teaches does not explicitly teach wherein the mobile number input box is automatically filled with the first mobile number.
In an analogous art, Everson teaches wherein the mobile number input box is automatically filled with the first mobile number (Everson: Para. [0228], Further, it should be appreciated that the mobile number may be obtained automatically, semi-automatically, or via user input depending on the particular embodiment. For example, some mobile device operating systems (e.g., Android operating systems) may allow the mobile application to access the mobile number via a simple prompt, whereas other mobile device operating systems (e.g., iOS operating systems) may require the user to manually enter the mobile number into the application.).
It would have been obvious to a person having ordinary skill in the art, before the effective filing date of the claimed invention, to combine the teachings of Everson with the system and method of Cronkright and Ma to include wherein the mobile number input box is automatically filled with the first mobile number because this functionality provides more efficient and user friendly entry of mobile numbers when requesting verification codes (Everson: Para. [0228]).
Regarding claim 36, Cronkright, in combination with Ma, teaches the method of claim 30, wherein triggering the mobile phone to receive verification information corresponding to the target website based on the first mobile number comprises sending the first mobile number to a server of the target website, to cause the server to send verification information to the mobile phone according to the first mobile number (Cronkright: Fig. 10C-2, Para. [0160], Para. [0162], At step 918, the ST server 104 receives the OTC request and the MCD information transmitted by the registered user's mobile communication device 102A and compares the received MCD information to MCD information stored in the user's account data 502. When, at step 920, the ST server 104 finds a match between the received MCD information and the MCD information stored in the user's account data 502, the process 900 advances to step 924 where the ST server 104 is operable to generate a one-time code and to transmit the generated OTC to the matching mobile communication device 102A. For example, the ST server transmits the generated OTC to the registered user's mobile communication device 102A that transmitted the OTC request. Ma: Para. [0269], The foregoing first operation may be an operation of tapping a “Next” control in the interface shown in FIG. 3B(c); or the first operation may be an operation of another type, for example, a voice instruction used for instructing to register with MeeTime. This is not limited in this embodiment of this application. Para. [0270]-[0272], Para. [0273]).
Cronkright, in combination with Ma, does not explicitly teach automatically when the mobile number input box is filled with the first mobile number.
In an analogous art, Everson teaches automatically when the mobile number input box is filled with the first mobile number (Everson: Para. [0228], Further, it should be appreciated that the mobile number may be obtained automatically, semi-automatically, or via user input depending on the particular embodiment. For example, some mobile device operating systems (e.g., Android operating systems) may allow the mobile application to access the mobile number via a simple prompt, whereas other mobile device operating systems (e.g., iOS operating systems) may require the user to manually enter the mobile number into the application.).
It would have been obvious to a person having ordinary skill in the art, before the effective filing date of the claimed invention, to combine the teachings of Everson with the system and method of Cronkright and Ma to include automatically when the mobile number input box is filled with the first mobile number because this functionality provides more efficient and user friendly entry of mobile numbers when requesting verification codes (Everson: Para. [0228]).
Regarding Claim 41, Claim 41 is rejected under the same rational as claim 31.
Regarding Claim 46, Claim 46 is rejected under the same rational as claim 36.
Claim(s) 32 and 42 are rejected under 35 U.S.C. 103 as being unpatentable over Cronkright et al. (US 2024/0205218; Hereinafter “Cronkright”) in view of Ma et al. (US 2023/0388782; Hereinafter “Ma”) in view of Meena (US 2019/0182248; Hereinafter “Meena”).
Regarding claim 32, Cronkright, in combination with Ma, teaches the method of claim 30, further comprising: displaying, after obtaining the first mobile number, a first number option that comprises at least part of the first mobile number (Ma: Fig 3B(c): Para. [0269], The interface includes a mobile phone number input box, and the user may enter a mobile phone number in the input box, for example, 185 xxxx xxxx.).
Cronkright, in combination with Ma, does not explicitly teach filling the mobile number input box with the first mobile number in response to a selection operation for the first number option.
In an analogous art, Meena teaches filling the mobile number input box with the first mobile number in response to a selection operation for the first number option (Meena: Para. [0041], The user 110 can select user's country by using a drop down list 602 that automatically fills in a country code box 603, then user 110 can fill in the user's cell phone number in a box 604 and move onto next step 605.).
It would have been obvious to a person having ordinary skill in the art, before the effective filing date of the claimed invention, to combine the teachings of Meena with the system and method of Cronkright and Ma to include filling the mobile number input box with the first mobile number in response to a selection operation for the first number option because this functionality provides for verification of identity information related to a user when an email address is unknown (Meena: Para. [0005]).
Regarding Claim 42, Claim 42 is rejected under the same rational as claim 32.
Claim(s) 33 and 43 are rejected under 35 U.S.C. 103 as being unpatentable over Cronkright et al. (US 2024/0205218; Hereinafter “Cronkright”) in view of Ma et al. (US 2023/0388782; Hereinafter “Ma”) in view of Zhu et al. (US 2025/0265324; Hereinafter “Zhu”).
Regarding claim 33, Cronkright, in combination with Ma, teaches the method of claim 30, and filling the mobile number input box with the first mobile number in response to a selection operation for the first number option.
Cronkright, in combination with Ma, does not explicitly teach further comprising: obtaining, in response to the second operation, a second mobile number of the mobile phone from the mobile phone, wherein the first mobile number is different from the second mobile number; displaying a first number option and a second number option, wherein the first number option comprises at least part of the first mobile number and the second number option comprises at least part of the second mobile number.
In an analogous art, Zhu teaches further comprising: obtaining, in response to the second operation, a second mobile number of the mobile phone from the mobile phone, wherein the first mobile number is different from the second mobile number (Zhu: Fig. 4, For example, after detecting that the user selects the “One-tap login” icon by using the remote control, the smart television may display, for example, the third interface shown in FIG. 4. Device names, namely, “Mobile phone A” and “Mobile phone B”, are displayed on the third interface.);
displaying a first number option and a second number option, wherein the first number option comprises at least part of the first mobile number and the second number option comprises at least part of the second mobile number (Zhu: Fig. 4, For example, after detecting that the user selects the “One-tap login” icon by using the remote control, the smart television may display, for example, the third interface shown in FIG. 4. Device names, namely, “Mobile phone A” and “Mobile phone B”, are displayed on the third interface. [Mobile phone A and Mobile phone B includes a first phone identifier and a second phone identifier respectively] Para. [0080], Para. [0082]).
It would have been obvious to a person having ordinary skill in the art, before the effective filing date of the claimed invention, to combine the teachings of Zhu with the system and method of Cronkright and Ma to include further comprising: obtaining, in response to the second operation, a second mobile number of the mobile phone from the mobile phone, wherein the first mobile number is different from the second mobile number; displaying a first number option and a second number option, wherein the first number option comprises at least part of the first mobile number and the second number option comprises at least part of the second mobile number because this functionality provides selection of a target device associated with a specific phone number to receive the verification code (Zhu: Para. [0005]).
Regarding Claim 43, Claim 43 is rejected under the same rational as claim 33.
Claim(s) 38 and 48 are rejected under 35 U.S.C. 103 as being unpatentable over Cronkright et al. (US 2024/0205218; Hereinafter “Cronkright”) in view of Ma et al. (US 2023/0388782; Hereinafter “Ma”) in view of Wentker et al. (US 2009/0037982; Hereinafter “Wentker”).
Regarding claim 38, Cronkright, in combination with Ma, teaches the method of claim 30. Cronkright, in combination with Ma, does not explicitly teach wherein the first operation is received by a login filling plug-in, which queries one or more mobile numbers of the mobile phone from a first connection service module in response to the first operation, wherein the first connection service module obtains the one or more mobile numbers from the mobile phone, wherein the first connection service module sends the one or more mobile numbers to the login filling plug-in, and fills the first mobile number into the mobile number input box of a browser.
In an analogous art, Wentker teaches wherein the first operation is received by a login filling plug-in, which queries one or more mobile numbers of the mobile phone from a first connection service module in response to the first operation, wherein the first connection service module obtains the one or more mobile numbers from the mobile phone, wherein the first connection service module sends the one or more mobile numbers to the login filling plug-in, and fills the first mobile number into the mobile number input box of a browser (Wentker: Fig. 3, Para. [0079], The transaction initiation component 84 can facilitate a range of transaction initiation scenarios. The scenarios can be divided into those that allow the consumer's mobile number to be automatically passed to the merchant plug-in (MPI) 74, and those that allow the consumer's mobile number to be manually input. As noted above, the mobile phone number may be automatically passed to the merchant plug-in (MPI) 74 using IVR, USSD, SMS, or WAP. Para. [0067], The merchant 22 can then enter one or more of the alias identifiers into the merchant Web page interface 23 (step 2). Para. [0068], The merchant plug-in (MPI) 28 receives the alias identifier, and it is sent to the directory server (DS) 48 in a verification request message (VE Req(m)) (step 3). After receiving the verification request message, the directory server 48 queries the access control server 25 (step 3) in order to determine whether authentication is available for the presenter 21. In this example, the verification request message (VE Req(m)) includes an alias identifier such as the phone number of the mobile phone 40.).
It would have been obvious to a person having ordinary skill in the art, before the effective filing date of the claimed invention, to combine the teachings of Wentker with the system and method of Cronkright and Ma to include wherein the first operation is received by a login filling plug-in, which queries one or more mobile numbers of the mobile phone from a first connection service module in response to the first operation, wherein the first connection service module obtains the one or more mobile numbers from the mobile phone, wherein the first connection service module sends the one or more mobile numbers to the login filling plug-in, and fills the first mobile number into the mobile number input box of a browser because this functionality provides for fulfilling verification requests with browser plug-ins by transmitting phone identifiers associated with an account to determine an associated trusted party (Wentker: Para. [0009]).
Regarding Claim 48, Claim 48 is rejected under the same rational as claim 38.
Allowable Subject Matter
Regarding Claim 39, Claim 39 is objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims.
The following is an Examiner’s statement of reasons for allowance:
The closest prior art includes Cronkright et al. (US 2024/0205218; Hereinafter “Cronkright”) in view of Ma et al. (US 2023/0388782; Hereinafter “Ma”) in view of Wentker et al. (US 2009/0037982; Hereinafter “Wentker”). However, none of Cronkright, Ma, and Wentker teaches or suggests, alone or in combination, the particular combination of steps or elements as recited in claim 39. For example, none of the cited prior art teaches or suggest the steps of “triggering, by the browser, the login filling plug-in to query verification information corresponding to the target website; querying, by the login filling plug-in, the verification information from a first SMS message service module; querying, by the first SMS message service module, the verification information from the mobile phone by the first connection service module; obtaining, by the first connection service module, the verification information that corresponds to the target website and that is from a second connection service module of the mobile phone, and sending the verification information to the login filling plug-in by the first SMS message service module; and filling, by the login filling plug-in, the verification information into the verification code input box of the browser.” As a result, the claims are allowable over the cited prior art.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
U.S. Patent Application Publication No. US 2023/0123628 by Mandia et al.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Nelson Giddins whose telephone number is (571)272-7993. The examiner can normally be reached on Monday - Friday, 9:00 AM - 5:00 PM.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Linglan Edwards can be reached at (571) 270-5440. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/NELSON S. GIDDINS/ Primary Examiner, Art Unit 2408