DETAILED ACTION
This Non-Final Office Action is in response to Application filed on 07/21/2025. Claims 1-20 filed on 07/21/2025 are being considered on the merits.
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 .
Drawings
The drawings filed on07/21/2025 are accepted.
Information Disclosure Statement
The information disclosure statements (IDS) submitted on11/14/2025 and 12/04/225 have been considered. The submission is in compliance with the provisions of 37 CFR 1.97. Accordingly, an initialed and dated copy of Applicant's IDS form 1449 filed 11/14/2025 and 12/04/225 are attached to the instant Office action.
Double Patenting
The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory double patenting rejection is appropriate where the conflicting claims are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on nonstatutory double patenting provided the reference application or patent either is shown to be commonly owned with the examined application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. See MPEP § 717.02 for applications subject to examination under the first inventor to file provisions of the AIA as explained in MPEP § 2159. See MPEP §§ 706.02(l)(1) - 706.02(l)(3) for applications not subject to examination under the first inventor to file provisions of the AIA . A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b).
The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The filing date of the application in which the form is filed determines what form (e.g., PTO/SB/25, PTO/SB/26, PTO/AIA /25, or PTO/AIA /26) should be used. A web-based eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about eTerminal Disclaimers, refer to www.uspto.gov/patents/process/file/efs/guidance/eTD-info-I.jsp.
Claims 1-20 rejected on the ground of nonstatutory double patenting as being obvious over claims 1-20 of US 12407530 B2, hereinafter 530.
Instant Application 19/275,517
US 12407530 B2
1. A computer-implemented method comprising: receiving, from a first requesting entity, an authentication request to authenticate the first requesting entity to a first decentralized resource directory of a providing entity;
1. A computer-implemented method comprising: receiving, at a server that manages access to a first decentralized resource directory of a providing entity in a system of decentralized resource directories, via a first connection and from a first requesting entity, an authentication request to authenticate the first requesting entity to the first decentralized resource directory, wherein the authentication request identifies the first requesting entity;
generating, in response to the authentication request, an authentication challenge value and an authentication challenge key;
generating, in response to the authentication request, an authentication challenge value and an authentication challenge key;
providing, in response to the authentication request, an authentication challenge to the first requesting entity for the first requesting entity to store the authentication challenge value for the authentication challenge key in a second decentralized resource directory of the first requesting entity;
providing, via the first connection and in response to the authentication request, an authentication challenge to the first requesting entity that instructs the first requesting entity to store the authentication challenge value for the authentication challenge key in a defined location in a second decentralized resource directory of the system of decentralized resource directories that is associated with the first requesting entity;
receiving, a confirmation from the first requesting entity that the authentication challenge value has been stored;
receiving, via the first connection, a confirmation from the first requesting entity that the authentication challenge value has been stored by the first requesting entity for the authentication challenge key, in response to the authentication challenge, in the defined location in the second decentralized resource directory of the first requesting entity;
sending a first lookup request to the second decentralized resource directory for a value stored for the authentication challenge key in the second decentralized resource directory;
sending, via the second connection, a first lookup request for a value stored for the authentication challenge key in the defined location in the second decentralized resource directory of the first requesting entity;
receiving, from the second decentralized resource directory, a first response value in response to the first lookup request;
receiving, via the second connection and from the second decentralized resource directory, a first response value in response to the first lookup request;
comparing the first response value to the authentication challenge value to determine whether the first response value matches the authentication challenge value;
comparing the first response value to the authentication challenge value to determine whether the first response value matches the authentication challenge value;
in response to determining that the first response value matches the authentication challenge value, responding to the authentication request, with an indication that the first requesting entity is authenticated to the first decentralized resource directory.
Similarly, claims 11 and 16
in response to determining that the first response value matches the authentication challenge value, responding to the authentication request, via the first connection, with an indication that the first requesting entity is authenticated to the first decentralized resource directory.
2. The computer-implemented method of Claim 1, further comprising, in response to determining that the first response value does not match the authentication challenge value, dropping a first connection with the first requesting entity.
2. The computer-implemented method of claim 1, further comprising, in response to determining that the first response value does not match the authentication challenge value, dropping the first connection.
3. The computer-implemented method of Claim 1, further comprising: receiving, from the first requesting entity, while the first requesting entity is authenticated to the first decentralized resource directory, a second lookup request for a value for a key stored in the first decentralized resource directory; determining that the first requesting entity has been provided access to a first stored value for the key; retrieving the first stored value for the key; and providing the first stored value as a second response value to the first requesting entity, in response to the second lookup request.
3. The computer-implemented method of claim 1, further comprising: receiving, via the first connection and from the first requesting entity, while the first requesting entity is authenticated to the first decentralized resource directory, a second lookup request for a value for a key stored in the first decentralized resource directory; determining that the first requesting entity has been provided access to a first stored value for the key; retrieving the first stored value for the key; and providing the first stored value as a second response value to the first requesting entity, in response to the second lookup request.
4. The computer-implemented method of Claim 3, further comprising: receiving a third lookup request, via an unauthenticated connection and from an unauthenticated second requesting entity, for a value for the key stored in the first decentralized resource directory; retrieving a publicly accessible value for the key; and providing the publicly accessible value for the key as a third response value, to the unauthenticated second requesting entity, in response to the third lookup request.
4. The computer-implemented method of claim 3, further comprising: receiving a third lookup request, via an unauthenticated third connection and from an unauthenticated second requesting entity, for a value for the key stored in the first decentralized resource directory; retrieving a publicly accessible value for the key; and providing the publicly accessible value for the key as a third response value, to the second requesting entity, in response to the third lookup request.
5. The computer-implemented method of Claim 4, wherein the first stored value for the key provided to the first requesting entity is different from the publicly accessible value for the key.
5. The computer-implemented method of claim 4, wherein the first stored value for the key provided to the authenticated first requesting entity is different from the publicly accessible value for the key.
6. The computer-implemented method of Claim 4, further comprising: receiving, from a third requesting entity while the third requesting entity is authenticated to the first decentralized resource directory, a fourth lookup request for a value for the key stored in the first decentralized resource directory; determining that the third requesting entity has been provided access to a third stored value for the key, wherein the third stored value is different from the first stored value and the publicly accessible value for the key; retrieving the third stored value for the key; and providing the third stored value as a third response value to the third requesting entity, in response to the fourth lookup request.
6. The computer-implemented method of claim 4, further comprising: receiving, via a third connection and from a third requesting entity while the third requesting entity is authenticated to the first decentralized resource directory, a fourth lookup request for a value for the key stored in the first decentralized resource directory; determining that the third requesting entity has been provided access to a third stored value for the key, wherein the third stored value is different from the first stored value and the publicly accessible value for the key; retrieving the third stored value for the key; and providing the third stored value as a third response value to the third requesting entity, in response to the fourth lookup request.
7. The computer-implemented method of Claim 6, further comprising: connecting, before sending the response to the second lookup request, to a namespace directory to request connection information for the second decentralized resource directory; receiving, from the namespace directory, connection information from the second decentralized resource directory; and using the connection information for the second decentralized resource directory to establish a connection with the second decentralized resource directory.
7. The computer-implemented method of claim 3, further comprising: connecting, before sending the second lookup request, to a namespace directory to request connection information for the second decentralized resource directory; and using the connection information for the second decentralized resource directory to establish the second connection.
8. The computer-implemented method of Claim 3, wherein the authentication request and the second lookup request are received from a user device associated with the first requesting entity.
8. The computer-implemented method of claim 3, wherein the authentication request and the second lookup request are received from a user device associated with the first requesting entity.
9. The computer-implemented method of Claim 3, wherein the authentication request and the second lookup request are received from a server that services requests for the second decentralized resource directory.
9. The computer-implemented method of claim 3, wherein the authentication request and the second lookup request are received from a server that services requests for the second decentralized resource directory.
10. The computer-implemented method of Claim 1, wherein the authentication challenge value is a randomly-generated identifier.
10. The computer-implemented method of claim 1, wherein the authentication challenge value is a randomly-generated identifier.
12. The computer program product of Claim 11, wherein the operations further comprise: sending, while authenticated to the first decentralized resource directory, a first lookup request to the first decentralized resource directory for a value for a key stored in the first decentralized resource directory; and receiving, in response to the first lookup request, a first value for the key.
Similarly, claim 17.
12. The computer-readable storage medium of claim 11, wherein the operations further comprise: sending, while authenticated to the first decentralized resource directory and via the first connection, a first lookup request to the first decentralized resource directory for a value for a key stored in the first decentralized resource directory; and receiving, in response to the first lookup request, a first value for the key.
13. The computer program product of Claim 12, wherein the operations further comprise: sending, as an unauthenticated requesting entity, a second lookup request to the first decentralized resource directory for the value for the key stored in the first decentralized resource directory; and receiving, in response to the second lookup request, a second value for the key, wherein the second value is different from the first value.
Similarly, claim 18.
13. The computer-readable storage medium of claim 12, wherein the operations further comprise: sending, as an unauthenticated requesting entity, a second lookup request, via a second connection, to the first decentralized resource directory for the value for the key stored in the first decentralized resource directory; and receiving, in response to the second lookup request, a second value for the key, wherein the second value is different from the first value.
14. The computer program product of Claim 11, wherein the operations further comprise: connecting, before sending the authentication request, to a namespace directory to request connection information for the second decentralized resource directory; receiving, from the namespace directory, connection information for the second decentralized resource directory; and using the connection information for the second decentralized resource directory to establish a connection with the second decentralized resource directory.
Similarly claim 19.
14. The computer-readable storage medium of claim 11, wherein the operations further comprise: connecting, before sending the authentication request, to a namespace directory to request connection information for the first decentralized resource directory; and using the connection information for the first decentralized resource directory to establish the first connection.
15. The computer program product of Claim 11, wherein the authentication challenge value is a randomly-generated identifier generated by the providing entity.
Similarly, claim 20.
Although the conflicting claims are not identical, they are not patentably distinct from each other because claims 1-20 of 530 contain every element of claims 1-20 of the instant application.
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 for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 1-6, 8-9, 11, and 16 are rejected under 35 U.S.C. 103 as being unpatentable over Huang (US 20180367526 A1), hereinafter Huang in view of Azizi (US 8594632 B1), hereinafter Azizi.
Regarding claim 1, Huang teaches a computer-implemented method (Huang Abstract “Systems and methods for authenticating a user requesting access to a resource in a cloud-computing system.”) comprising:
receiving, from a first requesting entity, an authentication request to authenticate the first requesting entity to a first decentralized resource directory of a providing entity (Huang Figure 4 (402), [0063, 0082] discloses access request with authentication token, user and client information corresponding to the first entity, resource service and its memory and active directory in the cloud computing environment, as disclosed in Figures 3-4 and [0051], correspond to the providing entity and its associated first decentralized resource directory, first connection correspond to connection between the Client device and Remote service);
generating, in response to the authentication request, an authentication challenge value and an authentication challenge key (Huang Figure 4 (410) and [0073], where the authentication challenge questions with initial token and parameters, and its corresponding answer are generated as evidenced by the eventual responses in (420) and [0079-0080], where the eventual responses comprising multiple assertions from multiple authentication services, where the above corresponding to authentication challenge values and keys);
providing, in response to the authentication request, an authentication challenge to the first requesting entity for the first requesting entity to store the authentication challenge value for the authentication challenge key in a second decentralized resource directory of the first requesting entity (Huang Figure 4 (412), [0073, 0075], where the authentication challenge is transmitted to the client device, where the client device performs processing on the authentication challenge. The storing limitation above is construed as an intended use, the challenge including the initial token and parameters is eventually transmitted stored in the authentication service, second decentralized resource directory, as indicated in Figure 4 (410, 412, 414));
[receiving, a confirmation from the first requesting entity that the authentication challenge value has been stored];
sending a first lookup request to the second decentralized resource directory for a value stored for the authentication challenge key in the second decentralized resource directory (Huang [0075-0076] Figure 4 (412, 414) authentication request transmitted from the client device to the authentication services correspond to the first look up request);
receiving, from the second decentralized resource directory, a first response value in response to the first lookup request (Huang [0076] Figure 4 (416, 418) updated token transmitted as responses from the authentication services to the client device);
comparing the first response value to the authentication challenge value to determine whether the first response value matches the authentication challenge value (Huang Figure 4 and [0076] where the users’ responses are compared to the questions/challenges, [0062] “…additionally, any of the steps in process 400 may be performed on any client device, gateway device, cloud connector, resource service, authentication service, external cloud provider and associated services, and/or third-party server or computing device.”, where the comparing can be performed by a third party server); and
in response to determining that the first response value matches the authentication challenge value, responding to the authentication request, with an indication that the first requesting entity is authenticated to the first decentralized resource directory (Huang Figure 4 (426) and [0076, 0079] the authentication services after ensuring the user is authenticated, (420) in Figure 4 indicates the first connection communication between the client device and the resource service, where user authentication is successful (426), [0062] “…additionally, any of the steps in process 400 may be performed on any client device, gateway device, cloud connector, resource service, authentication service, external cloud provider and associated services, and/or third-party server or computing device.”, where the above step can be performed by a third party server).
Huang teaches the first connection between the resource service, i.e. service provider, and the client device, requesting entity, where the client device stores the initial token as part of the challenge value, at the authentication service, however, Huang does not disclose that the resource provider receives confirmation that a challenge value is stored. Emphasis in italic.
Azizi discloses receiving a confirmation from the first requesting entity that the authentication challenge value has been stored (Azizi Col. 6 line 33-36 “the pre-shared tag can be a particular phrase, challenge answer, or word confirmation that is previously agreed upon with trusted users and is stored in the contact list.”).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Huang to incorporate the teaching of Azizi to utilize the above feature, with the motivation of preventing a rogue device from capturing sensitive data, as recognized by (Azizi Col. 6 line 25-36 and throughout).
Regarding claim 11, claim 11 recites similar limitations to claim 1, therefore rejected with same rationale/motivation applied to claim 1.
Regarding claim 16, claim 11 recites similar limitations to claim 1, therefore rejected with same rationale/motivation applied to claim 1.
Regarding claim 2, Huang in view of Azizi teaches the computer-implemented method of Claim 1, further comprising, in response to determining that the first response value does not match the authentication challenge value, dropping a first connection with the first requesting entity (Huang Figure 4 (428) and [0076, 0079] discloses the authentication services after ensuring the user is not authenticated, (420) in Figure 4 indicates the first connection communication between the client device and the resource service, where user authentication is unsuccessful (428), where the service resource deny the client device access, [0062] “…additionally, any of the steps in process 400 may be performed on any client device, gateway device, cloud connector, resource service, authentication service, external cloud provider and associated services, and/or third-party server or computing device.”, where the above step can be performed by a third party server)). .
Regarding claim 3, Huang in view of Azizi teaches the computer-implemented method of Claim 1, further comprising: receiving, from the first requesting entity, while the first requesting entity is authenticated to the first decentralized resource directory, a second lookup request for a value for a key stored in the first decentralized resource directory (Huang Figure 4 (422) [0076, 0078] where multiple authentication services are utilized and multiple requests are provided by the client device, where one authentication service may be authenticated and the second request is issued to another authentication service for authentication) (Huang Figure 4 (422) [0076, 0078] where multiple authentication services are utilized and multiple requests are provided by the client device, where one authentication service may be authenticated and the second request is issued to another authentication service for authentication);
determining that the first requesting entity has been provided access to a first stored value for the key; retrieving the first stored value for the key; and providing the first stored value as a second response value to the first requesting entity, in response to the second lookup request (Huang Figure 4 (422) [0076, 0078], where the updated token is continuously updated by various authentication services, where the updated token correspond to a first stored value of the key, received by the client device between (416-418)).
Regarding claim 4, Huang in view of Azizi teaches the computer-implemented method of Claim 3, further comprising: receiving a third lookup request, via an unauthenticated connection and from an unauthenticated second requesting entity, for a value for the key stored in the first decentralized resource directory; retrieving a publicly accessible value for the key; and providing the publicly accessible value for the key as a third response value, to the unauthenticated second requesting entity, in response to the third lookup request (Huang discloses Figure 4 authenticating a plurality of client devices by various/plurality of hardware authentication services, as disclosed in [0040, 0054], which indicate that each authentication service is communicating with the client device via a separate connection, i.e. first, second, third, etc. connection. Huang further illustrates in Figure 1 and [0029] the method utilized for authenticating a plurality of client devices, e.g. various unauthenticated requesting entities, e.g. second requesting entity, which is requesting authentication, where the key corresponding to the updated tokens as illustrated in Figure 4).
Regarding claim 5, Huang in view of Azizi teaches the computer-implemented method of Claim 4, wherein the first stored value for the key provided to the first requesting entity is different from the publicly accessible value for the key (Huang discloses in Figure 4 (416) [0076, 0087-0088] the updated token continually being updated for each authentication service to include different assertions of success, where the assertions include parameters, where one corresponds to different values, examiner notes that there is no clarification in the claims as to what these recited values entail.).
Regarding claim 6, Huang in view of Azizi teaches the computer-implemented method of Claim 4, further comprising: receiving, from a third requesting entity while the third requesting entity is authenticated to the first decentralized resource directory, a fourth lookup request for a value for the key stored in the first decentralized resource directory; determining that the third requesting entity has been provided access to a third stored value for the key, wherein the third stored value is different from the first stored value and the publicly accessible value for the key; retrieving the third stored value for the key; and providing the third stored value as a third response value to the third requesting entity, in response to the fourth lookup request (Huang discloses Figure 4 authenticating a plurality of client devices by various/plurality of hardware authentication services, as disclosed in [0040, 0054], which indicate that each authentication service is communicating with the client device via a separate connection, i.e. first, second, third, fourth, etc. connection. Huang further illustrates in Figure 1 and [0029] the method utilized for authenticating a plurality of client devices, e.g. various requesting entities, e.g. second, third and fourth requesting entities, which is requesting authentication, where the different key values corresponding to the updated tokens accumulating assertions/parameters as illustrated in Figure 4, Huang further discloses in Figure 4 (416) [0076, 0087-0088] the updated token continually being updated for each authentication service to include assertions of success, where the assertions include parameters, where one corresponds to different values, examiner notes that there is no clarification in the claims as to what these recited values entail.).
Regarding claim 8, the computer-implemented method of Claim 3, wherein the authentication request and the second lookup request are received from a user device associated with the first requesting entity (Huang Figure 4 illustrates the client device making an access request [0063, 0082] discloses access request with authentication token, corresponding to the authentication request, client device further illustrates in (412-414 and 422) transmitting authentication requests, corresponding to the lookup requests).
Regarding claim 9, the computer-implemented method of Claim 3, wherein the authentication request and the second lookup request are received from a server that services requests for the second decentralized resource directory (Huang [0062] “ Alternatively or additionally, any of the steps in process 400 may be performed on any client device, gateway device, cloud connector, resource service, authentication service, external cloud provider and associated services, and/or third-party server or computing device.”).
Claims 7, 14 and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Huang (US 20180367526 A1), hereinafter Huang in view of Azizi (US 8594632 B1), hereinafter Azizi, and Choi (US 20080091615 A1), hereinafter Choi.
Regarding claim 7, Huang in view of Azizi teaches the computer-implemented method of Claim 6, further comprising: [connecting, before sending the response to the second lookup request, to a namespace directory to request] connection information for the second decentralized resource directory; receiving, from the namespace directory, connection information from the second decentralized resource directory; and using the connection information for the second decentralized resource directory to establish a connection with the second decentralized resource directory (Huang Figure 4 and [0073] discloses, (410) in figure 4, the authentication parameters, corresponding to connection information, i.e. identifying which hardware authentication services to connect to, where each hardware authentication service, as disclosed in [0054], represents a connection between the client device and the authentication service, [0062] “…additionally, any of the steps in process 400 may be performed on any client device, gateway device, cloud connector, resource service, authentication service, external cloud provider and associated services, and/or third-party server or computing device.”, where the connection can be performed with a third party server).
Huang in view of Azizi do not disclose the below limitation. Emphasis in italic.
Choi discloses connecting, before sending the second lookup request, to a namespace directory to request connection information for the second decentralized resource directory (Choi illustrates in Figures 1 and 4 transmitting a request for purchasing content to the first device, where [0046] discloses, before transmitting the request, the contents purchasing unit of the second device, connects to the contents service intermediating server 110, namespace, acquiring connection information on the first device, “ Before transmitting the request, the contents purchasing unit 131 can connect to the contents service intermediating server 110, browse the desired contents, and acquire connection information on the first device 120 providing the contents or connection information on the contents from the contents service intermediating server 110.”).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Huang in view of Azizi to incorporate the teaching of Choi to utilize the above feature, with the motivation of connecting to other devices and purchasing contents, as recognized by (Choi [0046]).
Regarding claim 14, Huang in view of Azizi teaches the computer program product of Claim 11, wherein the operations further comprise: connecting, [before sending the authentication request], to a namespace directory to request connection information for the second decentralized resource directory; receiving, from the namespace directory, connection information for the second decentralized resource directory; and using the connection information for the second decentralized resource directory to establish a connection with the second decentralized resource directory (Huang Figure 4 and [0073] discloses, (410) in figure 4, the authentication parameters, corresponding to connection information, i.e. identifying which hardware authentication services to connect to, where each hardware authentication service, as disclosed in [0054], represents a connection between the client device and the authentication service, [0062] “…additionally, any of the steps in process 400 may be performed on any client device, gateway device, cloud connector, resource service, authentication service, external cloud provider and associated services, and/or third-party server or computing device.”, where the connection can be performed with a third party server).
Huang does not disclose the limitations below. Emphasis in italic.
Choi discloses connecting, before sending the authentication request, to a namespace directory to request connection information for the first decentralized resource directory (Choi illustrates in Figures 1 and 4 transmitting a request for purchasing content to the first device, where [0046] discloses, before transmitting the request, the contents purchasing unit of the second device, connects to the contents service intermediating server 110, namespace, acquiring connection information on the first device, “ Before transmitting the request, the contents purchasing unit 131 can connect to the contents service intermediating server 110, browse the desired contents, and acquire connection information on the first device 120 providing the contents or connection information on the contents from the contents service intermediating server 110.”).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Huang to incorporate the teaching of Choi to utilize the above feature, with the motivation of connecting to other devices and purchasing contents, as recognized by (Choi [0046]).
Regarding claim 19, claim 19 recites similar limitations to claim 14, therefore rejected with same rationale/motivation applied to claim 14.
Claims 10, 15 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Huang (US 20180367526 A1), hereinafter Huang in view of Azizi (US 8594632 B1), hereinafter Azizi, and Ligatti (US 20160182500 A1), hereinafter Ligatti.
Regarding claim 10, Huang in view of Azizi teaches the computer-implemented method of Claim 1.
Ligatti teaches wherein the authentication challenge value is a randomly-generated identifier (Ligatti [0028] “the authentication challenge can comprise randomly generated data (i.e., a nonce)”, [0030] “the authentication challenge can be dynamically generated random data”).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Huang in view of Azizi to incorporate the teaching of Ligatti to utilize the above feature, with the motivation of advancing security by utilizing a challenge that is being used once, i.e. nonce, as recognized by (Ligatti [0028, 0030]).
Regarding claim 15, Huang in view of Azizi teaches the computer program product of Claim 11.
wherein the authentication challenge value [is a randomly-generated identifier] generated by the providing entity (Huang Figure 4 (410) and [0073], where the authentication challenge questions and answer are generated as evidenced by the eventual responses in (420) and [0079-0080], where the eventual responses comprising multiple assertions from multiple authentication services corresponding to authentication challenge values).
Huang in view of Azizi does not teach the below limitation.
Ligatti (US 20160182500 A1) teaches wherein the authentication challenge value is a randomly-generated identifier (Ligatti [0028] “the authentication challenge can comprise randomly generated data (i.e., a nonce)”, [0030] “the authentication challenge can be dynamically generated random data”).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Huang in view of Azizi to incorporate the teaching of Ligatti to utilize the above feature, with the motivation of advancing security by utilizing a challenge that is being used once, i.e. nonce, as recognized by (Ligatti [0028, 0030]).
Regarding claim 20, claim 20 recites similar limitations to claim 15, therefore rejected with same rationale/motivation applied to claim 15.
Claims 12-13 and 17-18 are rejected under 35 U.S.C. 103 as being unpatentable over Huang (US 20180367526 A1), hereinafter Huang in view of Azizi (US 8594632 B1), hereinafter Azizi, and Le (US 11546337 B2), hereinafter Le.
Regarding claim 12, Huang in view of Azizi teaches the computer program product of Claim 11.
While Huang discloses the token utilized for a time period within which the resource service may grant the client device access to its requests, however, Huang in view of Azizi do not explicitly disclose the below limitation where the subsequent requests for key/data, after authentication, is granted/provided.
Huang does not disclose the below limitation.
Le discloses wherein the operations further comprise: sending, while authenticated to the first decentralized resource directory, a first lookup request to the first decentralized resource directory for a value for a key stored in the first decentralized resource directory; and receiving, in response to the first lookup request, a first value for the key (Le discloses while the client is authenticated, a valid subsequent request is granted for obtaining data, as disclosed in Col. 15 line 55-67 and Col. 16 line 1-20).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Huang in view of Azizi to incorporate the teaching of Le to utilize the above feature, with the motivation of providing more efficient processing of subsequent access requests, as recognized by (Le Col. 17 line 27-28).
Regarding claim 17, claim 17 recites similar limitations to claim 12, therefore rejected with same rationale/motivation applied to claim 12.
Regarding claim 13, Huang in view of Azizi and Le teaches the computer program product of Claim 12.
Le discloses wherein the operations further comprise: sending, as an unauthenticated requesting entity, a second lookup request to the first decentralized resource directory for the value for the key stored in the first decentralized resource directory; and receiving, in response to the second lookup request, a second value for the key, wherein the second value is different from the first value (Le US 11546337 B2 discloses while the client is not authenticated, a request is not granted for obtaining data unless authentication is performed, as disclosed in Col. 15 line 55-67 and Col. 16 line 1-20, where the request can be sent to another storage node of 130 in storage 135, corresponding to second connection, where after authentication data is received, where data from a different storage is different from the first data).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Huang in view of Azizi to incorporate the teaching of Le to utilize the above feature, with the motivation of providing more efficient processing of subsequent access requests , as recognized by (Le Col. 17 line 27-28).
Regarding claim 18, claim 18 recites similar limitations to claim 13, therefore rejected with same rationale/motivation applied to claim 13.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure:
Melo (US 10756908 B1) discloses user authentication with self-signed certificate and identity verification.
Lemaitre (US 20200085408 A1) discloses obtaining the connection information from a database, receiving a request for review and transmitting a notification request to a push notification server.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to BASSAM A NOAMAN whose telephone number is (571)272-2705. The examiner can normally be reached Monday-Friday 8:30 AM-5:00PM.
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.
/BASSAM A NOAMAN/Primary Examiner, Art Unit 2497
Prosecution Insights