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 .
Priority
Acknowledgment is made of applicant’s claim for foreign priority under 35 U.S.C. 119 (a)-(d). The certified copy has been filed in parent Application No. JP2024-190830, filed
on 10/30/2024.
Claim Objections
3. Claim 2 is objected to because of the following informalities: “in association with each other” should change to “in association with first password and second password.” Appropriate correction is required.
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 text of those sections of Title 35, U.S. Code not included in this action can be found in a prior Office action.
Claim(s) 1-4, and 6 is/are rejected under 35 U.S.C. 103 as being unpatentable over Chae (US-20220309138-A1) in view of Shimakawa (US 20230267432 A1).
Regarding claim 1, Chae discloses an information processing apparatus comprising ([0038] “The user terminal 20 is a computer to be operated by a user. For example, the user terminal 20 is a cell phone (including smartphones), a portable information terminal (including tablet computers and wearable terminals), or a personal computer”;
one or more controllers ([0038] “In this embodiment, the user terminal 20 includes a control unit 21, a storage unit 22, a communication unit 23, an operation unit 24, a display unit 25, and a photographing unit 26”);
a communicator capable of communicating with a server via a network ([0037] “The server 10 is a server computer. The server 10 includes a control unit 11, a storage unit 12, and a communication unit 13. The control unit 11 includes at least one processor. The control unit 11 executes processing in accordance with programs and data stored in the storage unit 12. The storage unit 12 includes a main memory unit and an auxiliary memory unit. For example, the main memory unit is a volatile memory, for example, a RAM, and the auxiliary memory unit is a non-volatile memory such as a ROM, an EEPROM, a flash memory, or a hard disk drive. The communication unit 13 is a communication interface for wired communication or wireless communication, and performs data communication via the network N”; [0038] “The physical configuration of each of the control unit 21, the storage unit 22, and the communication unit 23 may be the same as those of the control unit 11, the storage unit 12, and the communication unit 13, respectively”), Note that a server is interpreted as server 10 and communicator is interpreted as communication unit 23;
the server executing first authentication based on first authentication information including an account name (pars. 79 & 154: server 10 authentiactes based on user ID/password or token; [0036] “There is now described an example of an embodiment of the present invention. FIG. 1 is a diagram for illustrating an overall configuration of the authentication system. As illustrated in FIG. 1, an authentication system S includes a server 10, a user terminal 20, and an authentication device 30, each of which can be connected to a network N, for example, the Internet. In FIG. 1, there is illustrated one server 10, one user terminal 20, and one authentication device 30, but there may be a plurality of each of those”; [0049] “In this embodiment, there is described a case in which the user selects any one of two authentication methods, that is, any one of two-dimensional code authentication and two-step authentication combining face authentication and passcode authentication. For example, the user performs predetermined use registration when using the authentication service provided by the authentication system S. In place of the user performing the use registration himself or herself, the use registration may be performed based on an operation by, for example, an operator in response to an application by the user for the use registration on a document. For example, a new user operates the user terminal 20 to upload his or her face photograph and a desired passcode together with his or her name, a password, and other such information to the authentication service provided by the authentication system S. When those pieces of information have been uploaded, the use registration is complete, and the user can use the authentication service”; [0072] “As described above, the authentication system S of this embodiment sufficiently enhances security while preventing a reduction in convenience by recording, in the server 10, the location where the user successfully performed the two-dimensional code authentication so that, from the next time and the subsequent times, the two-step authentication can be performed at the same location. The details of this technology are now described”; [0079] “For example, when the user performs use registration, a new record is created in the user database DB1. The new record stores the name, password, passcode, registration date and time of the passcode, telephone number, email address, face photograph in association with the user ID. When the user does not specify the user ID, the server 10 issues a new user ID”;) note that the user ID (e.g. user photograph, user ID, user terminal code, etc.) and first password is interpreted as a password (e.g. password, passcode, key, etc.) executed by server 10, and stored in data storage unit associated with the first authentication method and the first authentication information for the authentication device in reference Chae); and
a storge (See storage unit 22 in Figure 1),
wherein the one or more controllers receive a refresh token transmitted by the server according to a result of the first authentication ([0049] “In this embodiment, there is described a case in which the user selects any one of two authentication methods, that is, any one of two-dimensional code authentication and two-step authentication combining face authentication and passcode authentication. For example, the user performs predetermined use registration when using the authentication service provided by the authentication system S. In place of the user performing the use registration himself or herself, the use registration may be performed based on an operation by, for example, an operator in response to an application by the user for the use registration on a document. For example, a new user operates the user terminal 20 to upload his or her face photograph and a desired passcode together with his or her name, a password, and other such information to the authentication service provided by the authentication system S. When those pieces of information have been uploaded, the use registration is complete, and the user can use the authentication service”; [0079] “For example, when the user performs use registration, a new record is created in the user database DB1. The new record stores the name, password, passcode, registration date and time of the passcode, telephone number, email address, face photograph, and feature amount calculated based on the face photograph in association with the user ID. When the user does not specify the user ID, the server 10 issues a new user ID”; [0080] “When the token is issued to the user, the server 10 stores the token in association with the user ID of the user. The server 10 transmits the issued token to the user terminal 20. The user terminal 20 receives the token, and displays a two-dimensional code including the token on the display unit 25. The token in this embodiment is one-time information, and therefore the token becomes invalid when used in the two-dimensional code authentication. When the two-dimensional code authentication is executed again, a new token is issued. The token may be issued by any issuing method. For example, the token may be issued by an algorithm for generating a random character string. Further, in the case of setting an expiration date in the token, the expiration date may be stored in the user database DB1”; [0154] “When the two-dimensional code authentication is selected (Step S2: Two-Dimensional Code Authentication), the authentication device 30 displays guidance for the two-dimensional code authentication on the display unit 35 (Step S3). The screen display of the display unit 35 in Step S3 is the state illustrated in the upper part of FIG. 3. The user operates the user terminal 20 in accordance with the guidance for the two-dimensional code authentication to display the two-dimensional code. For example, the user terminal 20 transmits a token issuance request to the server 10. The server 10 receives the issuance request, issues a token, and transmits the issued token to the user terminal 20. The user terminal 20 displays a two-dimensional code including the received token. When the token is issued, input of a user ID and a password may be required. Further, when the button B35 c displayed on the display unit 35 is selected, the processing returns to Step S1”), note that the “refresh token” is interpreted as a token to the server is received when the existing token is expired; Server includes a control unit 11; The issued token with a user ID and the registered/legitimate user termina transmit token issuance request the server, prior to the server issuing the token to the user terminal according to the user ID illustrated in Figure 12).
Although Chae discloses a control storage of the refresh token in the storage (See storage unit 22 in Figure 1); Chae does not explicitly disclose a control storage based on a setting related to whether or not to store the refresh token in the storage. However, SHIMAKAWA discloses a storage (pars. 42-44: RAM 113/storage 114) receives a refresh token transmitted by the server according to a result of the first authentication (pars. 55-56: after authentication succeeds, access token included in token request response is stored) further a control storage of the refresh token in the storage based on a setting related to whether or not to store the refresh token in the storage (pars. 55-[0056] “For example, in a case where the received token request response indicates a success of the authentication, in the step S406, the image forming apparatus 101 displays a setting screen 600 shown in FIG. 6 on the console section 116. When the user selects a start button 601 on the setting screen 600, the image forming apparatus 101 stores an access token included in the token request response in the storage 114 in association with the user information of the transfer source. When the access token is stored in the storage 114, the image forming apparatus 101 displays the registration screen 500 shown in FIG. 5B on the console section 116. On the registration screen 500 shown in FIG. 5B, the user ID and the password, input by the user, are displayed as turned characters (asterisks in the illustrated example), and the registered name input by the user is displayed as it is. After that, when the user selects a logout button 502, the screen is changed to the home screen. On this home screen, a bank transfer information registration button 701, appearing in FIG. 7, for registering a transfer destination is displayed in place of the banking service initial setting button 303. After that, the present process is terminated”).
Chae and SHIMAKAWA are analogous in authentication systems that implement tokens in association with users. Therefore, it would have been obvious to one of the ordinary skill in the art before the effective filing date of the claimed invention to have modified Chae to incorporate the teachings of SHIMAKAWA to include a storage to determine a decision as to whether to store the token or not. Doing so allows a setting for users to determine a setting for the token (SHIMAKAWA [0038] The PC 102 is used to acquire and display a status of the image forming apparatus 101, configure settings of the image forming apparatus 101, and transmit print data to the image forming apparatus 101.).
Regarding the computer method claim 6, the claim recites similar limitations as the information processing apparatus claim 1, therefore, rejected based on the same rationale as claim 1.
Regarding claim 2, Chae discloses the information processing apparatus according to claim 1, wherein the first authentication information includes the account name and a first password ([0049] “In this embodiment, there is described a case in which the user selects any one of two authentication methods, that is, any one of two-dimensional code authentication and two-step authentication combining face authentication and passcode authentication. For example, the user performs predetermined use registration when using the authentication service provided by the authentication system S. In place of the user performing the use registration himself or herself, the use registration may be performed based on an operation by, for example, an operator in response to an application by the user for the use registration on a document. For example, a new user operates the user terminal 20 to upload his or her face photograph and a desired passcode together with his or her name, a password, and other such information to the authentication service provided by the authentication system S. When those pieces of information have been uploaded, the use registration is complete, and the user can use the authentication service”; [0079] “For example, when the user performs use registration, a new record is created in the user database DB1. The new record stores the name, password, passcode, registration date and time of the passcode, telephone number, email address, face photograph, and feature amount calculated based on the face photograph in association with the user ID. When the user does not specify the user ID, the server 10 issues a new user ID”;) note that the user ID (e.g. user photograph, user ID, user terminal code, etc.) and first password is interpreted as a password (e.g. password, passcode, key, etc.) stored in data storage unit associated with the authentication method and the first authentication information for the authentication device in reference Chae;
the storage stores a second password different from the first password and the account name in association with each other ([0132] “The data storage unit 200 is mainly implemented by the storage unit 22. The data storage unit 200 is configured to store the data required for the registration application. For example, the data storage unit 200 stores data of the face photograph of the user. The data storage unit 200 may also store a user ID and a password. Further, for example, the data storage unit 200 may store a two-dimensional code generation program or an application of the authentication service”; first password is stored in storage data unit associated with the user terminal; [0078] “FIG. 12 is a table for showing a data storage example of the user database DB1. As shown in FIG. 12, the user database DB1 stores various pieces of information about the user. The user database DB1 stores a user ID, a user name, a password, data of an uploaded face photograph, a face feature amount calculated from the face photograph, a passcode, a registration date and time of the passcode, a telephone number, an email address, a token, and the like. Those pieces of information stored in the user database DB1 are examples of the user information”, second password is stored in data storage unit/user database associated with the server; [0073] “FIG. 11 is a functional block diagram for illustrating an example of functions to be implemented by the authentication system S of this embodiment. In this example, the functions to be implemented by each of the server 10, the user terminal 20, and the authentication device 30 are described”; and
the one or more controllers execute second authentication based on the account name and the second password ([0157] “The server 10 receives the location ID and the token, and performs the two-dimensional code authentication based on the user database DB1 (Step S7). In Step S7, the server 10 refers to the user database DB1, and determines whether or not there is a user having a user ID associated with the received token. When there is a user having a user ID associated with the received token, the authentication is successful, and when there is not such a user, the authentication fails”), note that the second password is interpreted as a password (e.g. password, passcode, etc.) associated with the second authentication method and the second authentication information stored in a database DB1 in the data storage unit in the server in reference Chae.
10. Regarding claim 3, Chae and SHIMAKAWA discloses the information processing apparatus according to claim 2 listed above. However, Chae does not explicitly disclose the limitation listed below. SHIMAKAWA further discloses if the setting of storing the refresh token in the storage is made, the one or more controllers store the refresh token in association with the account name and the second password in the storage ([0056] “When the user selects a start button 601 on the setting screen 600, the image forming apparatus 101 stores an access token included in the token request response in the storage 114 in association with the user information of the transfer source. When the access token is stored in the storage 114, the image forming apparatus 101 displays the registration screen 500 shown in FIG. 5B on the console section 116. On the registration screen 500 shown in FIG. 5B, the user ID and the password, input by the user, are displayed as turned characters (asterisks in the illustrated example), and the registered name input by the user is displayed as it is”); [0058] “Thus, in the present embodiment, the user information of the transfer source is registered. Note that when a registration changing button (not shown) which is displayed when the user selects the menu button 301, a screen for changing the registered user information of the transfer source is displayed on the console section 116”, see Fig. 4 for the refresh token in the storage 114 in reference SHIMAKAWA; Note that the controller accepts an input of the recorded access token (e.g. user ID) and the second password (e.g. password.) is disclosed when the store-setting condition is reached; second password is interpreted as the server executing authentication for the service setting and inputting a “password” in the authentication setting as illustrated in Fig. 5B. First password is interpreted as the user requesting access to the registration screen as illustrated in Fig. 5A in reference SHIMAKAWA.
Chae and SHIMAKAWA are analogous in authentication systems that implement tokens in association with users. Therefore, it would have been obvious to one of the ordinary skill in the art before the effective filing date of the claimed invention to have modified Chae to incorporate the teachings of SHIMAKAWA to include a storage to determine a decision as to whether to store the token or not. Doing so allows a setting for users to determine a setting for the token (SHIMAKAWA [0038] The PC 102 is used to acquire and display a status of the image forming apparatus 101, configure settings of the image forming apparatus 101, and transmit print data to the image forming apparatus 101.).
11. Regarding claim 4, the combination of Chae and SHIMAKAWA discloses the information processing apparatus according to claim 3 listed above. However, Chae does not explicitly disclose the limitation listed below. SHIMAKAWA discloses if the setting of storing the refresh token in the apparatus is made, the one or more controllers accept an input of the account name and the second password ([0056] “When the user selects a start button 601 on the setting screen 600, the image forming apparatus 101 stores an access token included in the token request response in the storage 114 in association with the user information of the transfer source. When the access token is stored in the storage 114, the image forming apparatus 101 displays the registration screen 500 shown in FIG. 5B on the console section 116. On the registration screen 500 shown in FIG. 5B, the user ID and the password, input by the user, are displayed as turned characters (asterisks in the illustrated example), and the registered name input by the user is displayed as it is. After that, when the user selects a logout button 502, the screen is changed to the home screen. On this home screen, a bank transfer information registration button 701, appearing in FIG. 7 , for registering a transfer destination is displayed in place of the banking service initial setting button 303. ”), Note that the controller accepts an input of the recorded access token (e.g. user ID) and the second password (e.g. password) is disclosed when the store-setting condition is reached – Fig. 4 and Fig. 5B; See paragraph [0049] on the controller 110 is connected to the communication section interface 123 and configuring information for registration/authorization; and
transmit the refresh token stored in association with the input account name and second password in the storage, to the server using the communicator ([0104] “Referring to FIG. 24 , the user gives a transfer instruction (step S2401). More specifically, as the transfer instruction, the user selects the transfer amount on the transfer amount selection screen 1500 shown in FIG. 15 and further presses the confirm button 1501. The image forming apparatus 101 having received the transfer instruction from the user transmits a transfer instruction notification to the banking service resource server 105 (step S2402)”; [0105] “The banking service resource server 105 acquires the access token included in the received transfer instruction notification. The banking service resource server 105 transmits a query about the information of the acquired access token to the banking service API authorization server 104 (step S2403). The banking service API authorization server 104 transmits a response to the query to the banking service resource server 105 (step S2404). More specifically, the banking service API authorization server 104 transmits the corresponding information of the access token to the banking service resource server 105. The banking service resource server 105 determines validity based on the received information of the access token. For example, in a case where the information is valid, the banking service resource server 105 executes transfer processing for transferring money using the transfer destination information and the transfer amount, included in the transfer instruction notification received from the image forming apparatus 101 (step S2405). On the other hand, in a case where the information is invalid, the banking service resource server 105 does not execute the above-mentioned transfer processing”), Note that the recorded access token (account name) and the second password (e.g.. password) is transmitted to the authorization server when the store-setting condition is reached – See Fig. 24; See paragraph [0049] on the controller 110 is connected to the communication section interface 123 and configuring information for registration/authorization;
Chae and SHIMAKAWA are analogous in authentication systems that implement tokens in association with users. Therefore, it would have been obvious to one of the ordinary skill in the art before the effective filing date of the claimed invention to have modified Chae to incorporate the teachings of SHIMAKAWA to include a storage to determine a decision as to whether to store the token or not. Doing so allows a setting for users to determine a setting for the token (SHIMAKAWA [0038] The PC 102 is used to acquire and display a status of the image forming apparatus 101, configure settings of the image forming apparatus 101, and transmit print data to the image forming apparatus 101.).
12. Claim 5 is/are rejected under 35 U.S.C. 103 as being unpatentable over Chae (US-20220309138-A1) in view of SHIMAKAWA (US-20230267432-A1) in view of Soma (US 20210349667 A1).
13. Regarding claim 5, the combination of Chae and SHIMAKAWA discloses the information processing apparatus according to claim 3 listed above. Chae discloses the information processing apparatus comprising an operation inputter, wherein ([0039] “The operation unit 24 is an input device , and is, for example, a pointing device such as a touch panel and a mouse, a keyboard, or a button. The operation unit 24 transmits details of operation to the control unit 21. The display unit 25 is, for example, a liquid crystal display unit or an organic EL display unit. The display unit 25 displays an image in accordance with an instruction of the control unit 21”).
However, the combination Chae and SHIMAKAWA does not explicitly disclose the limitation listed below. Soma further discloses if the setting of not storing the refresh token in the storage is made, the one or more controllers accept an input of the account name and the first password using the operation inputter ([0091] “When the user inputs authentication information to the cloud print service used by the user to the authentication information input window on the chat room, the client computer 100 transmits the input authentication information to the cloud print service 400 (S828). In response to receiving the authentication information transmitted from the client computer 100, the authorization server 440 of the cloud print service 400 performs authentication based on the received authentication information”; [0125] “On the other hand, no access token corresponding to identification information on the message application service 600 is registered (S718, No), the processing unit 530 proceeds with the process with S719. In S719, the processing unit 530 causes the client computer 100 to display an authentication information input window. In details, the processing unit 530 transmits an authentication request for user authority to the cloud print service 400. In response to the authentication request, the cloud print service 400 returns an URL required for display of the authentication window to the print bot service 500. The processing unit 530 transmits the URL to the message application service 600. The URL is transmitted to the client computer 100 via the message application service 600. Accordingly, the authentication information input window as illustrated in the region 905 of FIG. 9 is displayed”); Note that first password is interpreted as “password” associated with the user terminal/device– See Fig. 9; Note that not storing the access token in recorded in the nonvolatile storage region - See Fig. 13; and
transmit the accepted account name and first password to the server using the communicator ([0088] “If a previously used access token is stored in the access token 1205 of the account information table 1201 of the database 550, the following process of S823 to S830 can be omitted. On the other hand, if no authority for the print bot service 500 to access the cloud print service 400, such as an access token or the like, is stored in the access token 1205, the cloud print service performs the following process of S823 to S830”; [0089] “The print bot service 500 transmits an authentication request to the cloud print service 400 that is the destination of document data or image data registered in the message application service 600 when the data is printed (S823). In response to this request, the authorization server 440 of the cloud print service 400 notifies the print bot service 500 of a URL to display an authentication window used for user authentication (a URL for an authority authentication request) (S824)”; [0090] “In response to receiving the URL for an authority authentication request from the cloud print service 400, the print bot service 500 notifies the message application service 600 of the URL (S825). In response to this notification, the message application service 600 notifies the client computer 100 of the URL (S826). The client computer 100 accesses the notified URL and displays, on a chat room, an authentication information input window used for inputting authentication information for login to the cloud print service 400 (S827). The window 905 of FIG. 9 is an example of the authentication information input window. The authentication information input window 905 is a window displayed by a web server on the client computer 100. Note that the content input to the authentication information input window is not limited to the above as long as it is information with which authentication to the cloud print service 400 can be performed”; [0091] “When the user inputs authentication information to the cloud print service used by the user to the authentication information input window on the chat room, the client computer 100 transmits the input authentication information to the cloud print service 400 (S828). In response to receiving the authentication information transmitted from the client computer 100, the authorization server 440 of the cloud print service 400 performs authentication based on the received authentication information”; [0092] “Note that, although only authentication is performed in this example, a window that inquires of the user whether or not to permit the print bot service 500 to access the cloud print service 400 may be displayed on the client computer 100 after the authentication is successful. In such a case, the cloud print service 400 proceeds with the process to S829 described later in accordance with that the print bot service 500 is permitted to access the cloud print service 400 by the user”).
Chae, SHIMAKAWA, and Soma are analogous in authentication systems that implement tokens in association with users. Therefore, it would have been obvious to one of the ordinary skill in the art before the effective filing date of the claimed invention to have modified Chae in view of SHIMAKAWA to incorporate the teachings of Soma to include a controller storage to accept input when the setting of not storing the token is made and . Doing so would strengthen encryption (Soma“[0047] The file storage 410 stores a print job transmitted to a printer via the communication unit 430. The authorization server 440 has an authentication module used for performing an authentication process on the user who accesses the cloud print service 400. The authorization server 440 further manages authentication information required for accessing account information stored in the database 450”).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's
disclosure. Towata (US 20130097686 A1) discloses the web browser transmitting authentication information or an authentication token, which is obtained in response to an input operation on an authentication information input screen displayed by execution of the script, to the coordination device. (See Fig.1).
Any inquiry concerning this communication or earlier communications from the examiner should be directed to VIVIAN D. HO whose telephone number is (571)272-9957. The examiner can normally be reached M- TH 9:00 - 6:00; F 9:00-1:00.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Eleni A. Shiferaw can be reached at (571) 272-3867. 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.
/VIVIAN D HO/Examiner, Art Unit 2497 /ELENI A SHIFERAW/Supervisory Patent Examiner, Art Unit 2497
Prosecution Insights