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 .
Status of Claims
Claims 1-20 are pending; of which claims 12-16, 18-20 are withdrawn.
Election/Restrictions
Applicant’s election of Group I, claims 1-11, and 17, in the reply filed on 6/17/2026 is acknowledged. Because applicant did not distinctly and specifically point out the supposed errors in the restriction requirement, the election has been treated as an election without traverse (MPEP § 818.01(a)).
Information Disclosure Statement
The information disclosure statement (IDS) submitted on 10/29/2024 is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
The information disclosure statement (IDS) submitted on 6/6/2025 is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is 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.
Claim(s) 1-3, 5-11, 17 is/are rejected under 35 U.S.C. 103 as being unpatentable over Ito (PGPUB 2022/0269770), and further in view of Bhasin et al (PGPUB 2022/0271935).
Regarding Claim 1:
Ito teaches a system, comprising a first electronic device ([0182] device 2-2), a second electronic device ([0187] setting tool 5-2), and an authorization server ([0174] server apparatus 1-2), wherein:
the first electronic device is configured to:
send a device code request to the authorization server when a third-party application on the first electronic device requests to obtain a user authorization ([0193] the communication unit 31 of the device 2-2 transmits an authorization request to the server apparatus 1-2 (step S64); the authorization request is a request that the device 2-2 indirectly requests permission for the installer 104 to validate the device key);
the authorization server is configured to:
generate, based on the device code request, a device code and a user code that correspond to the third-party application, and a uniform resource locator (URL) corresponding to an authorization page, and send, to the first electronic device, the device code, the user code, and the URL corresponding to the authorization page ([0198] next, when the communication unit 11 of the server apparatus 1-2 receives the authorization request from the device 2-2, the authentication unit 12 authenticates authenticity of the authorization request (step S65); [0200] next, the processing unit 19 creates an authorization response, and the communication unit 11 returns the authorization response to the device 2-2; the authorization response includes the following information; [0201] Device code generated in step S66; [0202] User code generated in step S66; [0203] Expiration set in step S66; [0204] Verification URI (uniform resource indicator); [0205] the verification URI is a URI prepared in advance by the server apparatus 1-2; in a later step, a setting tool 5-2 accesses this URI in response to an operation input of the installer 104, and the server apparatus 1-2 responds to the access);
the first electronic device is further configured to:
send, to the second electronic device, the user code, and the URL corresponding to the authorization page ([0206] next, the device 2-2 temporarily records the authorization response received from the server apparatus 1-2, and displays the verification URI and the user code on the display 41 (step S68); for example, the display 41 displays the verification URI as a QR code and displays the user code as a character string; furthermore, for example, when the server apparatus 1-2 includes the verification URI incorporating the user code in the authorization response, the display 41 may only display the verification URI as the QR code; for example, when the device 2-2 displays these pieces of information on the display 41, the device 2-2 may output a sound or blink an LED to attract the attention of the installer 104; [0207] next, the camera 56 of the setting tool 5-2 reads the verification URI and the user code displayed on the display 41 of the device 2-2 in response to the operation of the installer 104 (step S69));
the second electronic device is configured to:
send an authorization page request to the authorization server based on the user code and the URL corresponding to the authorization page ([0208] next, the server communication unit 51 accesses the verification URI read in step S69 (step S70); in response to the request sent from the setting tool 5-2 to the verification URI, the server apparatus 1-2 returns a verification web page, requesting the installer 104 for permission for validation of the device key, to the setting tool 5-2);
the authorization server is further configured to:
generate the authorization page based on the authorization page request, and send the authorization page to the second electronic device ([0208] in response to the request sent from the setting tool 5-2 to the verification URI, the server apparatus 1-2 returns a verification web page, requesting the installer 104 for permission for validation of the device key, to the setting tool 5-2), wherein the authorization page comprises an indication of a permission to be granted to the third-party application ([0208] the server apparatus 1-2 returns a verification web page, requesting the installer 104 for permission for validation of the device key, to the setting tool 5-2);
the second electronic device is further configured to:
obtain a permission that a user agrees to grant, and send, to the authorization server, the permission that the user agrees to grant ([0208] in response to the request sent from the setting tool 5-2 to the verification URI, the server apparatus 1-2 returns a verification web page, requesting the installer 104 for permission for validation of the device key, to the setting tool 5-2; [0210] next, when the server communication unit 51 of the setting tool 5-2 transmits the user code to the server apparatus 1 via the verification web page, the processing unit 19 of the server apparatus 1 verifies the user code (step S72); a form of the verification web page may accept an input of the user code from the installer 104; for example, the setting tool 5-2 may read the user code directly from the display 41 of the device 2-2 and transmit the user code to the server apparatus 1-2; when the processing unit 19 receives the user code from the setting tool 5-2, the processing unit 19 reads the entry including the user code from the authorization code storage unit 20; the processing unit 19 verifies that the expiration field of the entry is a time later than the current time and that a verification completion flag is “not completed”; [0211] when the verification in step S72 is passed, the processing unit 19 updates the entry and sets “completed” in the verification completion flag field (step S73));
the first electronic device is further configured to:
send an authorization code request to the authorization server, wherein the authorization code request comprises the device code ([0213] next, the activation token request unit 43 of the device 2-2 sends an activation token issue request to the server apparatus 1-2 via the communication unit 31 (step S75); this transmission of the activation token issue request is performed asynchronously with an act of the installer 104 after the device 2-2 displays the user code and the verification URI on the display 41; the activation token issue request includes the following information; [0214] device code received from server apparatus 1-2 in authorization response); and
the authorization server is further configured to:
after obtaining the authorization code request, determine, based on the device code, the permission that the user agrees to grant, generate an authorization code based on the permission that the user agrees to grant, and send the authorization code to the first electronic device ([0219] next, when the communication unit 11 of the server apparatus 1-2 receives the activation token issue request from the device 2-2, the processing unit 19 authenticates authenticity of the activation token issue request (step S76); [0220] next, when the verification in step S76 is passed, the issue unit 16 verifies the device code included in the activation token issue request (step S77); specifically, the issue unit 16 confirms that the user code corresponding to the device code included in the activation token issue request has been received from the setting tool 5-2; furthermore, the issue unit 16 reads the entry including the received device code from the authorization code storage unit 20; the issue unit 16 verifies that the expiration of the entry is a time later than the current time, that the activation key identifier of the entry is the same as the activation key identifier included in the request, and that the verification completion flag of the entry is “completed”; [0222] next, when the verification in step S77 is passed, the issue unit 16 issues an activation token and returns the activation token to the device 2-2 (step S78)).
Ito does not explicitly teach wherein the authorization page comprises a selection button corresponding to each permission;
the second electronic device is further configured to:
display the authorization page, and
obtain, in response to a selection operation on the permission indicated on the authorization page, a permission that a user agrees to grant.
However, Bhasin teaches the concept wherein an authorization page comprises a selection button corresponding to each permission ([0063] the user 100 is presented with an access grant page (e.g., a GUI) on the second system's website 256, where the user 100 selects one or more selectable options to choose one or more grants; a grant may include a permission or authorization to allow the access of particular information and/or to enable access to services 270 of the second system 106; the grant may allow the first system 108 to enable access to the service and/or the information on behalf of the user 100);
a second electronic device is further configured to:
display the authorization page ([0060] the user 100 navigates to a website or service 258 operated by the first system 108; the user may navigate to the first system's website or service 258 using a user device 104; [0061] the first system's website 258 redirects the user 100 to a website or service 256 operated by the second system for authentication; [0063] access grant page (e.g., a Graphical User Interface (GUI)), and
obtain, in response to a selection operation on the permission indicated on the authorization page, a permission that a user agrees to grant ([0063] the user 100 is presented with an access grant page (e.g., a GUI) on the second system's website 256, where the user 100 selects one or more selectable options to choose one or more grants; after the user 100 makes a selection, an API (e.g., “Enroll” API function) of the authorization system 102 is invoked from the second system's website 256 to communicate the following data: a) client identifier (e.g., an identifier for the computing device (client) being provided access, which is previously registered with the first system and received by the client identifier outside of this flow); b) first system identifier (e.g. an identifier for the first system 108, such as a merchant identifier); and c) one or more grants).
It would have been obvious to one or ordinary skill in the art before the effective filing date of the claimed invention to combine the authorization user interface teachings of Bhasin with the asynchronous authentication system of Ito, with the benefit of providing a clear, easy-to-understand visual interface that can be clearly understood by human users when deciding to grant access privileges to a device/application, thereby improving user experience, clarity, and eliminating unnecessary ambiguity which could lead to accidentally granting excess permissions which would reduce the security level.
Regarding Claim 2:
Ito in view of Bhasin teaches the system according to claim 1. In addition, Ito teaches wherein the authorization server comprises at least a first interface, a second interface, a third interface, and a fourth interface ([0174] FIG. 9 is a view illustrating an example of a functional configuration of a server apparatus 1-2 of the second embodiment; the server apparatus 1-2 of the second embodiment includes the communication unit 11, the authentication unit 12, the user account storage unit 13, the activation key storage unit 14, the device key storage unit 15, the issue unit 16, the activation token storage unit 17, the server key storage unit 18, the processing unit 19, and an authorization code storage unit 20; a difference from the configuration of the server apparatus 1 of the first embodiment is that the authorization code storage unit 20 is further provided in the present embodiment); and
the first interface is configured to send the device code request to the authorization server ([0198] the communication unit 11 of the server apparatus 1-2 receives the authorization request from the device 2-2; [0199] processing unit generates device code in response),
the second interface is configured to send the authorization page request to the authorization server ([0208] in response to the request sent from the setting tool 5-2 to the verification URI, the server apparatus 1-2 returns a verification web page; [0209] the authentication unit 12 of the server apparatus 1-2 authenticates that a person accessing the verification web page is the installer 104 (step S71)),
the third interface is configured to send, to the authorization server, the permission that the user agrees to grant ([0210] the server communication unit 51 of the setting tool 5-2 transmits the user code to the server apparatus 1 via the verification web page, the processing unit 19 of the server apparatus 1 verifies the user code (step S72); a form of the verification web page may accept an input of the user code from the installer 104; for example, the setting tool 5-2 may read the user code directly from the display 41 of the device 2-2 and transmit the user code to the server apparatus 1-2; when the processing unit 19 receives the user code from the setting tool 5-2, the processing unit 19 reads the entry including the user code from the authorization code storage unit 20), and
the fourth interface is configured to send the authorization code request to the authorization server ([0213] the activation token request unit 43 of the device 2-2 sends an activation token issue request to the server apparatus 1-2 via the communication unit 31 (step S75)).
Regarding Claim 3:
Ito in view of Bhasin teaches the system according to claim 1. In addition, Ito teaches wherein the authorization server generates the user code using randomization ([0199] the processing unit 19 generates and sets different random character strings in a device code field and a user code field).
Regarding Claim 5:
Ito in view of Bhasin teaches the system according to claim 1. In addition, Bhasin teaches wherein the device code request comprises the permission to be granted to the third-party application ([0063] the user 100 is presented with an access grant page (e.g., a GUI) on the second system's website 256, where the user 100 selects one or more selectable options to choose one or more grants; the first system 108 may submit a list of grants and the user 100 may grant the first system 108 all, some, or none of the grants submitted by the first system 108); and
Ito teaches after generating, based on the device code request, the device code, the user code, and the URL corresponding to the authorization page ([0199] next, the processing unit 19 creates a new entry in the authorization code storage unit 20 and issues the authorization code (step S66); at that time, the processing unit 19 generates and sets different random character strings in a device code field and a user code field; [0205] the verification URI is a URI prepared in advance by the server apparatus 1-2), the authorization server is further configured to:
associatively store the user code, the permission to be granted to the third-party application ([0175] the following information is recorded in an entry of the authorization code storage unit 20; [0176] Device code; [0177] User code; [0178] Expiration; [0179] Activation key identifier used for authorization request; [0180] Verification completion flag), and the URL corresponding to the authorization page ([0200] next, the processing unit 19 creates an authorization response, and the communication unit 11 returns the authorization response to the device 2-2; the authorization response includes the following information; [0201] Device code generated in step S66; [0202] User code generated in step S66; [0203] Expiration set in step S66; [0204] Verification URI (uniform resource indicator); [0205] the verification URI is a URI prepared in advance by the server apparatus 1-2; in a later step, a setting tool 5-2 accesses this URI in response to an operation input of the installer 104, and the server apparatus 1-2 responds to the access; [0206] next, the device 2-2 temporarily records the authorization response received from the server apparatus 1-2).
The rationale to combine Ito and Bhasin is the same as provided for claim 1 due to the overlapping subject matter between claims 1 and 5.
Regarding Claim 6:
Ito in view of Bhasin teaches the system according to claim 5. In addition, Bhasin teaches wherein the authorization server is further configured to:
determine, based on the user code in the authorization page request, the permission to be granted to the third-party application ([0061] in Step 202, the first system's website 258 redirects the user 100 to a website or service 256 operated by the second system for authentication; [0062] in Step 203, the user 100 logs into the second system's website 256 and is authenticated with the user's credentials; [0063] in Step 204, the user 100 is presented with an access grant page (e.g., a GUI) on the second system's website 256, where the user 100 selects one or more selectable options to choose one or more grants; the grants available for selection may vary depending on the user 100 and/or the entity associated with the first system 108), and
generate the authorization page based on the permission to be granted to the third-party application ([0063] in Step 204, the user 100 is presented with an access grant page (e.g., a GUI) on the second system's website 256; the grants available for selection may vary depending on the user 100 and/or the entity associated with the first system 108).
The rationale to combine Ito and Bhasin is the same as provided for claim 1 due to the overlapping subject matter between claims 1 and 6.
Regarding Claim 7:
Ito in view of Bhasin teaches the system according to claim 1. In addition, Ito teaches wherein the authorization server is specifically configured to:
after obtaining the authorization code request, determine the user code based on the device code ([0213] next, the activation token request unit 43 of the device 2-2 sends an activation token issue request to the server apparatus 1-2 via the communication unit 31 (step S75); the activation token issue request includes the following information; [0214] Device code received from server apparatus 1-2 in authorization response; [0215] Activation key identifier of device 2-2; [0216] Time at which activation token issue request has been created; [0217] Randomly generated activation token issue request identification character string; [0218] Electronic signature created with activation key (private key) for all the above information; [0219] next, when the communication unit 11 of the server apparatus 1-2 receives the activation token issue request from the device 2-2, the processing unit 19 authenticates authenticity of the activation token issue request (step S76); specifically, the processing unit 19 performs electronic signature verification using the activation key (public key), and the like, similarly to the authentication of the authorization request; [0220] next, when the verification in step S76 is passed, the issue unit 16 verifies the device code included in the activation token issue request (step S77); specifically, the issue unit 16 confirms that the user code corresponding to the device code included in the activation token issue request has been received from the setting tool 5-2),
determine, based on the user code, the permission that the user agrees to grant ([0220] the issue unit 16 confirms that the user code corresponding to the device code included in the activation token issue request has been received from the setting tool 5-2 (EXAMINER’S NOTE: the user code must be confirmed to continue, i.e. next steps are determined “based on” the user code); furthermore, the issue unit 16 reads the entry including the received device code from the authorization code storage unit 20; the issue unit 16 verifies that the expiration of the entry is a time later than the current time, that the activation key identifier of the entry is the same as the activation key identifier included in the request, and that the verification completion flag of the entry is “completed”), and
generate the authorization code based on the permission that the user agrees to grant ([0222] next, when the verification in step S77 is passed, the issue unit 16 issues an activation token and returns the activation token to the device 2-2 (step S78)).
Regarding Claim 8:
Ito in view of Bhasin teaches the system according to claim 1. In addition, Ito teaches wherein a size of a display of the first electronic device is less than a size of a display of the second electronic device ([0033] the setting tool 5 is, for example, a tool (such as notebook PC) used by the installer 104 for the setting operation; [0241] the hardware configurations of main parts of the device 2, the registration tool 4, and the setting tools 5 to 5-2 of the first and second embodiments are also similar to the hardware configurations of the server apparatuses 1 to 1-2; note that, in the device 2, a part of the hardware configuration (for example, display device 304, input device 305, and the like) may be deleted; [0224] in the above example, the device 2-2 uses the display 41 and the setting tool 5-2 uses the camera 56 to transmit the user code and the verification URI; however, the user code and the verification URI may be transmitted by another method; for example, the user code and the verification URI may be transmitted by a method such as infrared communication, visible light communication, voice communication, or ultrasonic communication; EXAMINER’S NOTE: Ito therefore envisions a first device, i.e. device 2, without a display, and a second device, i.e. setting tool 5, with a display).
Regarding Claim 9:
Ito in view of Bhasin teaches the system according to claim 1. In addition, Bhasin teaches wherein a user account for logging in to the second electronic device is a target account ([0208] next, the server communication unit 51 accesses the verification URI read in step S69 (step S70); in response to the request sent from the setting tool 5-2 to the verification URI, the server apparatus 1-2 returns a verification web page, requesting the installer 104 for permission for validation of the device key, to the setting tool 5-2; [0209] next, the authentication unit 12 of the server apparatus 1-2 authenticates that a person accessing the verification web page is the installer 104 (step S71); the authentication in step S71 may be, for example, authentication using a user identifier and a password of the installer 104 stored in the user account storage unit 13, or authentication using a token acquired in advance by OAuth 2.0 Authorization Code Flow), and the target account has an authorization permission for data that the third-party application requests to access ([0208, [0209] as above).
Regarding Claim 10:
Ito in view of Bhasin teaches the system according to claim 1. In addition, Ito teaches wherein a distance between the first electronic device and the second electronic device is less than or equal to a preset distance threshold ([0224] in the above example, the device 2-2 uses the display 41 and the setting tool 5-2 uses the camera 56 to transmit the user code and the verification URI; however, the user code and the verification URI may be transmitted by another method; for example, the user code and the verification URI may be transmitted by a method such as infrared communication, visible light communication, voice communication, or ultrasonic communication; EXAMINER’S NOTE: a ‘preset distance threshold’ is established by the maximum communication range of each communication methodology).
Regarding Claim 11:
Ito teaches a method, applied to a first electronic device ([0182] device 2-2), the method comprising:
sending a device code request to an authorization server when a third-party application on the first electronic device requests to obtain a user authorization ([0193] the communication unit 31 of the device 2-2 transmits an authorization request to the server apparatus 1-2 (step S64); the authorization request is a request that the device 2-2 indirectly requests permission for the installer 104 to validate the device key);
obtaining a device code, a user code, and a uniform resource locator (URL) corresponding to an authorization page that are returned by the authorization server, wherein the device code, the user code, and the URL corresponding to the authorization page are determined by the authorization server based on the device code request ([0198] next, when the communication unit 11 of the server apparatus 1-2 receives the authorization request from the device 2-2, the authentication unit 12 authenticates authenticity of the authorization request (step S65); [0200] next, the processing unit 19 creates an authorization response, and the communication unit 11 returns the authorization response to the device 2-2; the authorization response includes the following information; [0201] Device code generated in step S66; [0202] User code generated in step S66; [0203] Expiration set in step S66; [0204] Verification URI (uniform resource indicator); [0205] the verification URI is a URI prepared in advance by the server apparatus 1-2; in a later step, a setting tool 5-2 accesses this URI in response to an operation input of the installer 104, and the server apparatus 1-2 responds to the access);
sending, to a second electronic device, the user code and the URL corresponding to the authorization page ([0206] next, the device 2-2 temporarily records the authorization response received from the server apparatus 1-2, and displays the verification URI and the user code on the display 41 (step S68); for example, the display 41 displays the verification URI as a QR code and displays the user code as a character string; furthermore, for example, when the server apparatus 1-2 includes the verification URI incorporating the user code in the authorization response, the display 41 may only display the verification URI as the QR code; for example, when the device 2-2 displays these pieces of information on the display 41, the device 2-2 may output a sound or blink an LED to attract the attention of the installer 104; [0207] next, the camera 56 of the setting tool 5-2 reads the verification URI and the user code displayed on the display 41 of the device 2-2 in response to the operation of the installer 104 (step S69));
sending an authorization code request to the authorization server ([0213] next, the activation token request unit 43 of the device 2-2 sends an activation token issue request to the server apparatus 1-2 via the communication unit 31 (step S75); this transmission of the activation token issue request is performed asynchronously with an act of the installer 104 after the device 2-2 displays the user code and the verification URI on the display 41; the activation token issue request includes the following information; [0214] device code received from server apparatus 1-2 in authorization response); and
obtaining an authorization code returned by the authorization server, wherein the authorization code request comprises the device code ([0219] next, when the communication unit 11 of the server apparatus 1-2 receives the activation token issue request from the device 2-2, the processing unit 19 authenticates authenticity of the activation token issue request (step S76); [0220] next, when the verification in step S76 is passed, the issue unit 16 verifies the device code included in the activation token issue request (step S77); specifically, the issue unit 16 confirms that the user code corresponding to the device code included in the activation token issue request has been received from the setting tool 5-2; furthermore, the issue unit 16 reads the entry including the received device code from the authorization code storage unit 20; the issue unit 16 verifies that the expiration of the entry is a time later than the current time, that the activation key identifier of the entry is the same as the activation key identifier included in the request, and that the verification completion flag of the entry is “completed”; [0222] next, when the verification in step S77 is passed, the issue unit 16 issues an activation token and returns the activation token to the device 2-2 (step S78); [0213] the activation token issue request includes the following information; [0214] device code received from server apparatus 1-2 in authorization response), wherein:
the authorization code is generated by the authorization server based on a permission that a user agrees to grant and that is determined based on the device code after the authorization code request is obtained ([0219] next, when the communication unit 11 of the server apparatus 1-2 receives the activation token issue request from the device 2-2, the processing unit 19 authenticates authenticity of the activation token issue request (step S76); [0220] next, when the verification in step S76 is passed, the issue unit 16 verifies the device code included in the activation token issue request (step S77); specifically, the issue unit 16 confirms that the user code corresponding to the device code included in the activation token issue request has been received from the setting tool 5-2; furthermore, the issue unit 16 reads the entry including the received device code from the authorization code storage unit 20; the issue unit 16 verifies that the expiration of the entry is a time later than the current time, that the activation key identifier of the entry is the same as the activation key identifier included in the request, and that the verification completion flag of the entry is “completed”; [0222] next, when the verification in step S77 is passed, the issue unit 16 issues an activation token and returns the activation token to the device 2-2 (step S78); EXAMINER’S NOTE: issuing of the activation token only occurs after the device code and verification flag (i.e. user permission grant) are verified, and is therefore “based on” the device code and the permission granted by the user, i.e. “installer”),
the permission that the user agrees to grant is determined by the second electronic device ([0208] the server apparatus 1-2 returns a verification web page, requesting the installer 104 for permission for validation of the device key, to the setting tool 5-2), and
the authorization page is generated by the authorization server based on the user code and the URL corresponding to the authorization page that are sent by the second electronic device ([0208] next, the server communication unit 51 accesses the verification URI read in step S69 (step S70); in response to the request sent from the setting tool 5-2 to the verification URI, the server apparatus 1-2 returns a verification web page, requesting the installer 104 for permission for validation of the device key, to the setting tool 5-2).
Ito does not explicitly teach the permission that the user agrees to grant is determined by the second electronic device based on a selection operation corresponding to a permission indicated on the authorization page.
However, Bhasin teaches the concept that a permission that a user agrees to grant is determined by a second electronic device based on a selection operation corresponding to a permission indicated on an authorization page ([0063] the user 100 is presented with an access grant page (e.g., a GUI) on the second system's website 256, where the user 100 selects one or more selectable options to choose one or more grants; a grant may include a permission or authorization to allow the access of particular information and/or to enable access to services 270 of the second system 106; the grant may allow the first system 108 to enable access to the service and/or the information on behalf of the user 100).
It would have been obvious to one or ordinary skill in the art before the effective filing date of the claimed invention to combine the authorization user interface teachings of Bhasin with the asynchronous authentication system of Ito, with the benefit of providing a clear, easy-to-understand visual interface that can be clearly understood by human users when deciding to grant access privileges to a device/application, thereby improving user experience, clarity, and eliminating unnecessary ambiguity which could lead to accidentally granting excess permissions which would reduce the security level.
Regarding Claim 17:
Ito teaches a first electronic device ([0182] device 2-2; [0241] the hardware configurations of main parts of the device 2, the registration tool 4, and the setting tools 5 to 5-2 of the first and second embodiments are also similar to the hardware configurations of the server apparatuses 1 to 1-2), comprising at least one memory ([0231] memory), at least one processor ([0231] control device), and a computer program that can be run on the at least one processor and that is stored in the at least one memory, wherein when the at least one processor executes the computer program, the first electronic device is caused to ([0231] control device 301 executes a program read from the auxiliary storage device 303 to the main storage device 302):
send a device code request to an authorization server when a third-party application on the first electronic device requests to obtain a user authorization ([0193] the communication unit 31 of the device 2-2 transmits an authorization request to the server apparatus 1-2 (step S64); the authorization request is a request that the device 2-2 indirectly requests permission for the installer 104 to validate the device key);
obtain a device code, a user code, and a uniform resource locator (URL) corresponding to an authorization page that are returned by the authorization server, wherein the device code, the user code, and the URL corresponding to the authorization page are determined by the authorization server based on the device code request ([0198] next, when the communication unit 11 of the server apparatus 1-2 receives the authorization request from the device 2-2, the authentication unit 12 authenticates authenticity of the authorization request (step S65); [0200] next, the processing unit 19 creates an authorization response, and the communication unit 11 returns the authorization response to the device 2-2; the authorization response includes the following information; [0201] Device code generated in step S66; [0202] User code generated in step S66; [0203] Expiration set in step S66; [0204] Verification URI (uniform resource indicator); [0205] the verification URI is a URI prepared in advance by the server apparatus 1-2; in a later step, a setting tool 5-2 accesses this URI in response to an operation input of the installer 104, and the server apparatus 1-2 responds to the access);
send, to a second electronic device, the user code and the URL corresponding to the authorization page ([0206] next, the device 2-2 temporarily records the authorization response received from the server apparatus 1-2, and displays the verification URI and the user code on the display 41 (step S68); for example, the display 41 displays the verification URI as a QR code and displays the user code as a character string; furthermore, for example, when the server apparatus 1-2 includes the verification URI incorporating the user code in the authorization response, the display 41 may only display the verification URI as the QR code; for example, when the device 2-2 displays these pieces of information on the display 41, the device 2-2 may output a sound or blink an LED to attract the attention of the installer 104; [0207] next, the camera 56 of the setting tool 5-2 reads the verification URI and the user code displayed on the display 41 of the device 2-2 in response to the operation of the installer 104 (step S69));
send an authorization code request to the authorization server ([0213] next, the activation token request unit 43 of the device 2-2 sends an activation token issue request to the server apparatus 1-2 via the communication unit 31 (step S75); this transmission of the activation token issue request is performed asynchronously with an act of the installer 104 after the device 2-2 displays the user code and the verification URI on the display 41; the activation token issue request includes the following information; [0214] device code received from server apparatus 1-2 in authorization response); and
obtain an authorization code returned by the authorization server, wherein the authorization code request comprises the device code ([0219] next, when the communication unit 11 of the server apparatus 1-2 receives the activation token issue request from the device 2-2, the processing unit 19 authenticates authenticity of the activation token issue request (step S76); [0220] next, when the verification in step S76 is passed, the issue unit 16 verifies the device code included in the activation token issue request (step S77); specifically, the issue unit 16 confirms that the user code corresponding to the device code included in the activation token issue request has been received from the setting tool 5-2; furthermore, the issue unit 16 reads the entry including the received device code from the authorization code storage unit 20; the issue unit 16 verifies that the expiration of the entry is a time later than the current time, that the activation key identifier of the entry is the same as the activation key identifier included in the request, and that the verification completion flag of the entry is “completed”; [0222] next, when the verification in step S77 is passed, the issue unit 16 issues an activation token and returns the activation token to the device 2-2 (step S78); [0213] the activation token issue request includes the following information; [0214] device code received from server apparatus 1-2 in authorization response), wherein:
the authorization code is generated by the authorization server based on a permission that a user agrees to grant and that is determined based on the device code after the authorization code request is obtained ([0219] next, when the communication unit 11 of the server apparatus 1-2 receives the activation token issue request from the device 2-2, the processing unit 19 authenticates authenticity of the activation token issue request (step S76); [0220] next, when the verification in step S76 is passed, the issue unit 16 verifies the device code included in the activation token issue request (step S77); specifically, the issue unit 16 confirms that the user code corresponding to the device code included in the activation token issue request has been received from the setting tool 5-2; furthermore, the issue unit 16 reads the entry including the received device code from the authorization code storage unit 20; the issue unit 16 verifies that the expiration of the entry is a time later than the current time, that the activation key identifier of the entry is the same as the activation key identifier included in the request, and that the verification completion flag of the entry is “completed”; [0222] next, when the verification in step S77 is passed, the issue unit 16 issues an activation token and returns the activation token to the device 2-2 (step S78); EXAMINER’S NOTE: issuing of the activation token only occurs after the device code and verification flag (i.e. user permission grant) are verified, and is therefore “based on” the device code and the permission granted by the user, i.e. “installer”),
the permission that the user agrees to grant is determined by the second electronic device ([0208] the server apparatus 1-2 returns a verification web page, requesting the installer 104 for permission for validation of the device key, to the setting tool 5-2), and
the authorization page is generated by the authorization server based on the user code and the URL corresponding to the authorization page that are sent by the second electronic device ([0208] next, the server communication unit 51 accesses the verification URI read in step S69 (step S70); in response to the request sent from the setting tool 5-2 to the verification URI, the server apparatus 1-2 returns a verification web page, requesting the installer 104 for permission for validation of the device key, to the setting tool 5-2).
Ito does not explicitly teach the permission that the user agrees to grant is determined by the second electronic device based on a selection operation corresponding to a permission indicated on the authorization page.
However, Bhasin teaches the concept that a permission that a user agrees to grant is determined by a second electronic device based on a selection operation corresponding to a permission indicated on an authorization page ([0063] the user 100 is presented with an access grant page (e.g., a GUI) on the second system's website 256, where the user 100 selects one or more selectable options to choose one or more grants; a grant may include a permission or authorization to allow the access of particular information and/or to enable access to services 270 of the second system 106; the grant may allow the first system 108 to enable access to the service and/or the information on behalf of the user 100).
It would have been obvious to one or ordinary skill in the art before the effective filing date of the claimed invention to combine the authorization user interface teachings of Bhasin with the asynchronous authentication system of Ito, with the benefit of providing a clear, easy-to-understand visual interface that can be clearly understood by human users when deciding to grant access privileges to a device/application, thereby improving user experience, clarity, and eliminating unnecessary ambiguity which could lead to accidentally granting excess permissions which would reduce the security level.
Claim(s) 4 is/are rejected under 35 U.S.C. 103 as being unpatentable over Ito in view of Bhasin, and further in view of Bao et al (PGPUB 2014/0282884).
Regarding Claim 4:
Ito in view of Bhasin teaches the system according to claim 1. In addition, Ito teaches wherein the device code request comprises a client identifier of the third-party application ([0193] next, the communication unit 31 of the device 2-2 transmits an authorization request to the server apparatus 1-2 (step S64); the authorization request is a request that the device 2-2 indirectly requests permission for the installer 104 to validate the device key; the authorization request includes the following information; [0194] Activation key identifier of device 2-2; [0195] Creation time of authorization request; [0196] Request identification character string randomly generated in device 2-2; [0197] Electronic signature created with activation key (private key) for all the above information).
Neither Ito nor Bhasin explicitly teaches the authorization server is further configured to:
combine the user code and the client identifier of the third-party application in a preset combination to obtain combination information, and
encrypt the combination information, by using a preset encryption algorithm, to obtain the device code.
However, Bao teaches the concept that an authorization server is configured to:
combine a user code and a client identifier of a third-party application in a preset combination to obtain combination information ([0036] various embodiments of the present disclosure support providing the specific application the pseudonymous profile of a particular user; in some embodiments, the particular user's user identification (UID) can be combined with the specific application's identification, and encrypted into a hashed ID; the specific application only has access to the hashed ID unless explicitly authorized by the particular user; upon the user's authorization, an access token is provided to the specific application to access a subset of the particular user's fully identifying profile), and
encrypt the combination information, by using a preset encryption algorithm, to obtain a device code ([0036] the particular user's user identification (UID) can be combined with the specific application's identification, and encrypted into a hashed ID).
It would have been obvious to one or ordinary skill in the art before the effective filing date of the claimed invention to combine the encrypted combination code teachings of Bao with the asynchronous authentication system of Ito in view of Bhasin, with the benefit of improving the security of a credential by increasing the entropy through the combination of multiple identifiers and a hash/encryption algorithm, thereby making it more difficult for an attacker or impersonator to acquire the original components of the token for tracking or exploit purposes.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to FORREST L CAREY whose telephone number is (571)270-7814. The examiner can normally be reached 9:00AM-5:30PM M-F.
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, William Korzuch can be reached at (571) 272-7589. 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.
/FORREST L CAREY/Examiner, Art Unit 2491
/WILLIAM R KORZUCH/Supervisory Patent Examiner, Art Unit 2491
