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 . In communications filed on 01/13/2026. Claims 1, 6, 8, 11, 14, 18, and 19 are amended. Claims 1-20 are pending in this examination.
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. This examination is in response to US Patent Application No. 16/630,658.
Response to Arguments
Applicant's arguments filed 01/13/2026 have been fully considered but they are not persuasive:
Applicant submits on page 12 of remarks filed on 01/13/2026 that the amendments to claim 1 serve to reinforce that the claimed base token that applies to multiple users and the authentication deltas for the first and second users are received by a sender system, rather than by the recipient systems associated with the first and second users. The sender system or another service subsequently assembles authentication tokens from the base token and authentication deltas and transmits the assembled authentication tokens to the corresponding recipient systems.
Examiner respectfully disagrees with applicant argument for claim 1 filed on 01/13/2026 on page 12 of remarks.
Examiner Note: The amendment claims 1 renders the claim indefinite because , the sender receives first user and second user information and adds these to base token and then transmit the authentication token to recipients and recipient validates that these communications are from first and second users , but the claim does not indicate if the first user or second users have account within the sender system? And what is the purpose of sender device receiving this information for first user and second user? And when the recipient receives the second user information from the sender , how it validates that the communication is from second user since it is receiving this information from the sender device? Is the sender device associated with the first user and the second user at the same time?
Applicant in page 11, of the remarks states that “ in claim 1, the authorization service sends a base token and authentication deltas to a sender system, which the sender system assembles itself or using another service into respective authentication tokens for recipients. The sender system or the other service then relays the authentication tokens to the recipient systems” .
Based on the applicant remark it looks like the sender device is a relay device and not a stand-alone device, however this is not claimed and the sender device in claim 1 does not act as a relay device and it could be a stand-alone device and based on this the claim limitations in claim 1 are vague.
Applicant’s arguments with respect to independent claims for newly added limitation have been considered but are moot because the arguments do not apply to any of the references being used in the current rejection.
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 of this title, 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-16, and 18-20 are rejected under 35 U.S.C. 103 as being unpatentable over Seidman (US2024/0080200), and in view of Engan (US2019/0124070), and further in view of Hires (US2021/0141888).
Regarding claim 1, Seidman discloses in a computer system, a method comprising: transmitting, from a sender system to an authorization service a request for a first authentication token and a second authentication token [Abstract, A method includes receiving, by a client ( equated to sender system), from an identity service provider( equated to authorization service), an authentication token associated with a user of the client], and [¶43, For example, as shown in FIG. 4, the client 210 receives the authentication token from the identity service provider 400. The identity service provider 400 is a third-party service that can validate the user 240 is who they claim or purport to be]; and
responsive to the request, from the authorization service with the sender system, receiving , a base token that applies to multiple users [ ¶43, the authentication token ( equated to base token) is JavaScript Object Notation (JSON) web token (JWT) ( the token can be applied to many users].
Seidman does not explicitly disclose. However, Engan discloses:
an authentication delta for a first user among the multiple users, and an authentication delta for a second user among the multiple users, the authentication delta for the first user comprising a first signature for the first user and a first claim representing an immutable identifier of the first user, and the authentication delta for the second user comprising a second signature for the second user and a second claim representing an immutable identifier of the second user [¶¶41-46, FIG. 3 depicts an authentication token 300 according to one or more implementations of the techniques described herein. The authentication token 300 is shown as a data structure having a format of a standard JSON Web Token (JWT), but other formats may be used without departing from the scope of the claims appended hereto. The authentication token 300 includes a header 302, a payload 304, and a signature 306. The header 302 includes header data 308 that is typically, but not necessarily, made up of two parts: a type of the token, and a digital signing algorithm used with the token (e.g., HMAC SHA256, RSASSA-PSS, etc.). The header data 308 is encoded using Base64, Base64url, or some other mutually recognized scheme to produce the header 302.In this example, the header indicates that the token type is a JSON Web Token, and that the PS256 algorithm was used with the token. The payload 304 (sometimes referred to as a “body”), includes statements about an entity and may contain additional data. In the example provided, the payload 304 includes at least a client public key 310 (similar to the client public key 228 of FIG. 2) and a unique user identifier (UUID) associated with the client device 202 (FIG. 2). Typically, the payload 304 will also contain other information, such as information that identifies an issuer of the token, a subject of the token, an expiration time of the token, etc. The client public key 310, and other data (if present), is encoded to produce the payload 304. Although such encoding is shown in FIG. 3 as being according to Base64, any known method of encoding may be used as long as it suits the purposes of the techniques described herein. In this example, the payload identifies an issuer as “account.t-mobile.com,” a UUID as “U-96be1cf7-0f9f-450c-bdbe-11d6e12f9926” and a client public key. The signature 306 is created by signing the encoded header 302 and the encoded payload 304 with an identity provider private key 312 such as the IDP private key 230 of FIG. 2). The signature 306 is created using the digital signature algorithm identified in the header data 308 (e.g., HMAC SHA256, RSASSA-PSS, etc.). The signature 306 is used to verify that the sender of the token is who it claims it is, and to ensure that the message wasn't changed since originating from the sender]; and
with the sender system or another service assembling the first authentication token by combining the base token with the authentication delta for the first user; assembling the second authentication token by combining the base token with the authentication delta for the second user [ see FIG. 3 and associated text for more detail, ¶¶41-47]; and
transmitting the first authentication token and a first communication to a recipient system associated with the first user wherein the first authentication token is usable by the recipient system associated with the first user to validate that the first communication is intended for the first user; and transmitting the second authentication token and a second communication to a recipient system associated with the second user wherein the second authentication token is usable by the recipient system associated with the second user to validate that the second communication is intended for the second user
while Seidman discloses [¶43, For example, as shown in FIG. 4, the client 210 receives the authentication token from the identity service provider 400. The identity service provider 400 is a third-party service that can validate the user 240 is who they claim or purport to be]; and
Seidman does not explicitly disclose. However, Engan discloses this limitation as:
[¶79, a server 504 (FIG. 5) running a secure service receives a request to access the secure service from a client device 502 at block 1002. The request includes an authentication token 512 and a POP token 514. In at least one implementation, the request is an HTTP request that includes the authentication token 512 and the POP token 514 in an authorization header, though other request formats may be used].
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teaching of Seidman by incorporating “improved authentication token and usage”, as taught by Engan. One could have been motivated to do so in order for the client to provide an authorization token and a proof-of-possession (POP) token in the secure access request to a service provider. [ Engan, ¶15].
Even though Seidman, and Engan do not explicitly disclose second user or multiple users, however It would have been obvious to one of ordinary skill in the art to apply the method of Seidman application and Engan application for multiple clients /users and generation of multiple authentication tokens for different users.
However, Hires discloses:
[¶43, The mobile device 1001 is communicatively coupled to the cloud server 1003 through the network 1005 for the purposes of authenticating a user. All user related data required for authentication is stored in the mobile device 1001, and if needed, is shared with the cloud server 1003 after encryption in the form of an encrypted blob. Further, after encryption, a digital token, such as a digital identification (ID) is generated which is used to identify the user in the cloud server 1003. When multiple users are using the cloud server 1003 as a provider of authentication services, each individual user can be identified by their respective digital tokens and use the combination of cloud server 1003 and the mobile device 1001 for authenticating their respective user in a plurality of applications].
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teaching of Seidman, Engan by incorporating “ digital identity management systems”, as taught by Hires. One could have been motivated to do so in order to when multiple users are using the cloud server as a provider of authentication services, each individual user can be identified by their respective digital tokens [ Hires, ¶¶ 2, 43].
Regarding claim 2, Seidman discloses wherein the base token comprises a third claim, wherein combining the base token with the authentication delta for the first user comprises populating a payload object of the first authentication token with the first claim and the third claim, and wherein combining the base token with the authentication delta for the second user comprises populating a payload object of the second authentication token with the second claim and the third claim [¶49-54, The password request includes the authentication token, the authorization token, the public key, the fully qualified domain name (FQDN) or internet protocol (IP) address, and the certificate hash of the client 210… The username can be determined by the control plane 150 and can be based, for example, an email address associated with the user or a User Principal Name (UPN)] …. The password can be generated, for example, if the user does not already have a password or one is not assigned to the user account… encrypting the password].
Regarding claim 3, Seidman, and Hires do not explicitly disclose. However, Engan discloses wherein combining the base token with the authentication delta for the first user further comprises populating a signature object of the first authentication token with the first signature, and wherein combining the base token with the authentication delta for the second user further comprises populating a signature object of the second authentication token with the second signature [ see FIG. 3 and associated text for more detail, ¶¶41-47].
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teaching of Seidman by incorporating “improved authentication token and usage”, as taught by Engan. One could have been motivated to do so in order for the client to provide an authorization token and a proof-of-possession (POP) token in the secure access request to a service provider. [ Engan, ¶15].
Regarding claim 4, Seidman, and Hires do not explicitly disclose. However, Engan discloses wherein the base token further comprises a header object, the header object comprising data representing a value of a field, wherein assembling the first authentication token further comprises populating a header object of the first authentication token with the data from the header object of the base token, and wherein assembling the second authentication token further comprises populating a header object of the second authentication token with the data from the header object of the base token [ see FIG. 3 and associated text for more detail, ¶¶41-47].
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teaching of Seidman and Hires by incorporating “improved authentication token and usage”, as taught by Engan. One could have been motivated to do so in order for the client to provide an authorization token and a proof-of-possession (POP) token in the secure access request to a service provider. [ Engan, ¶15].
Regarding claim 5, Seidman discloses wherein the data representing the value of the field, in the header object of the first authentication token, indicates that the first authentication token is a JavaScript Object Notation (JSON) web token (JWT) [ ¶43, the authentication token is JavaScript Object Notation (JSON) web token (JWT)].
Examiner note: Engan also discloses [¶41, FIG. 3 depicts an authentication token 300 according to one or more implementations of the techniques described herein. The authentication token 300 is shown as a data structure having a format of a standard JSON Web Token (JWT)].
Regarding claim 6, receiving a transformation delta comprising a fourth claim, the fourth claim having a same type as the third claim and a different value than the third claim; altering the first authentication token by replacing the value of the third claim with the value of the fourth claim; and transmitting the altered first authentication token to the recipient system associated with the first user
Hires does not explicitly disclose, however:
Seidman discloses: [¶49-54, The password request includes the authentication token, the authorization token, the public key, the fully qualified domain name (FQDN) or internet protocol (IP) address, and the certificate hash of the client 210… The username can be determined by the control plane 150 and can be based, for example, an email address associated with the user or a User Principal Name (UPN)] …. The password can be generated, for example, if the user does not already have a password or one is not assigned to the user account… encrypting the password].
Furthermore, Engan discloses [¶79, a server 504 (FIG. 5) running a secure service receives a request to access the secure service from a client device 502 at block 1002. The request includes an authentication token 512 and a POP token 514. In at least one implementation, the request is an HTTP request that includes the authentication token 512 and the POP token 514 in an authorization header, though other request formats may be used].
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teaching of Seidman and Hires by incorporating “improved authentication token and usage”, as taught by Engan. One could have been motivated to do so in order for the client to provide an authorization token and a proof-of-possession (POP) token in the secure access request to a service provider. [ Engan, ¶15].
Regarding claim 8, Seidman, Engan and Hires discloses these limitation transmitting the base token and respective authentication deltas for a plurality of users to a recipient service for assembly, wherein the recipient service is associated with the plurality of users, and wherein the recipient service performs the assembling the first authentication token, the assembling the second authentication token, the transmitting the first authentication token, and the transmitting the second authentication token
Seidman [ Abstract, ¶43].
Engan discloses [ see FIG. 3 and associated text for more detail, ¶¶41-47].
Hires discloses [¶43]
Regarding claim 9, Seidman discloses transmitting the first authentication token to a plurality of additional recipient systems associated with the first user [ ¶23, Applications associated with an enterprise may also include applications that allow communication between people, for example, email, messaging, web meetings, and so on].
Regarding claim 10, Seidman discloses wherein the plurality of additional recipient systems comprise one or more of a chat system and a meeting system [ ¶23, Applications associated with an enterprise may also include applications that allow communication between people, for example, email, messaging, web meetings, and so on.
Regarding claim 11, this claim is interpreted and rejected for the same rational set forth in claim 1.
Regarding claim 12, Seidman, and Hires do not explicitly disclose. However, Engan discloses wherein the first signature comprises a first string of characters, and wherein the second signature comprises a second string of characters different than the first string of characters [¶46… The signature 306 is created using the digital signature algorithm identified in the header data 308 (e.g., HMAC SHA256, RSASSA-PSS, etc.). The signature 306 is used to verify that the sender of the token is who it claims it is, and to ensure that the message wasn't changed since originating from the sender.].
Regarding claim 13, Seidman, and Hires do not explicitly disclose. However, Engan discloses wherein the base token comprises a type field, an algorithm field, and a third claim having a type and a value [¶¶41-46, FIG. 3 depicts an authentication token 300 according to one or more implementations of the techniques described herein. The authentication token 300 is shown as a data structure having a format of a standard JSON Web Token (JWT), but other formats may be used without departing from the scope of the claims appended hereto. The authentication token 300 includes a header 302, a payload 304, and a signature 306. The header 302 includes header data 308 that is typically, but not necessarily, made up of two parts: a type of the token, and a digital signing algorithm used with the token (e.g., HMAC SHA256, RSASSA-PSS, etc.). The header data 308 is encoded using Base64, Base64url, or some other mutually recognized scheme to produce the header 302.In this example, the header indicates that the token type is a JSON Web Token, and that the PS256 algorithm was used with the token. The payload 304 (sometimes referred to as a “body”), includes statements about an entity and may contain additional data. In the example provided, the payload 304 includes at least a client public key 310 (similar to the client public key 228 of FIG. 2) and a unique user identifier (UUID) associated with the client device 202 (FIG. 2). Typically, the payload 304 will also contain other information, such as information that identifies an issuer of the token, a subject of the token, an expiration time of the token, etc. The client public key 310, and other data (if present), is encoded to produce the payload 304. Although such encoding is shown in FIG. 3 as being according to Base64, any known method of encoding may be used as long as it suits the purposes of the techniques described herein. In this example, the payload identifies an issuer as “account.t-mobile.com,” a UUID as “U-96be1cf7-0f9f-450c-bdbe-11d6e12f9926” and a client public key. The signature 306 is created by signing the encoded header 302 and the encoded payload 304 with an identity provider private key 312 such as the IDP private key 230 of FIG. 2). The signature 306 is created using the digital signature algorithm identified in the header data 308 (e.g., HMAC SHA256, RSASSA-PSS, etc.). The signature 306 is used to verify that the sender of the token is who it claims it is, and to ensure that the message wasn't changed since originating from the sender]
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teaching of Seidman and Hires by incorporating “improved authentication token and usage”, as taught by Engan. One could have been motivated to do so in order for the client to provide an authorization token and a proof-of-possession (POP) token in the secure access request to a service provider. [ Engan, ¶15].
Regarding claim 14, Seidman discloses, wherein the operations further comprise: generating, with the authorization service, a transformation delta comprising a fourth claim, the fourth claim having a same type as the third claim and a different value than the third claim; and transmitting, from the authorization service to the sender system, the transformation delta to the sender system [¶49-54, The password request includes the authentication token, the authorization token, the public key, the fully qualified domain name (FQDN) or internet protocol (IP) address, and the certificate hash of the client 210… The username can be determined by the control plane 150 and can be based, for example, an email address associated with the user or a User Principal Name (UPN)] …. The password can be generated, for example, if the user does not already have a password or one is not assigned to the user account… encrypting the password].
Regarding claim 15, Seidman, and Hires do not explicitly disclose. However, Engan discloses, wherein the first and second authentication tokens are compressed authentication tokens, wherein generating the base token comprises generating an encoded string of characters representing the type field, the algorithm field, and the third claim, wherein generating the authentication delta for the first user comprises generating an encoded string of characters representing the first claim, and wherein generating the authentication delta for the second user comprises generating an encoded string of characters representing the second claim [¶¶41-46, FIG. 3 depicts an authentication token 300 according to one or more implementations of the techniques described herein. The authentication token 300 is shown as a data structure having a format of a standard JSON Web Token (JWT), but other formats may be used without departing from the scope of the claims appended hereto. The authentication token 300 includes a header 302, a payload 304, and a signature 306. The header 302 includes header data 308 that is typically, but not necessarily, made up of two parts: a type of the token, and a digital signing algorithm used with the token (e.g., HMAC SHA256, RSASSA-PSS, etc.). The header data 308 is encoded using Base64, Base64url, or some other mutually recognized scheme to produce the header 302.In this example, the header indicates that the token type is a JSON Web Token, and that the PS256 algorithm was used with the token. The payload 304 (sometimes referred to as a “body”), includes statements about an entity and may contain additional data. In the example provided, the payload 304 includes at least a client public key 310 (similar to the client public key 228 of FIG. 2) and a unique user identifier (UUID) associated with the client device 202 (FIG. 2). Typically, the payload 304 will also contain other information, such as information that identifies an issuer of the token, a subject of the token, an expiration time of the token, etc. The client public key 310, and other data (if present), is encoded to produce the payload 304. Although such encoding is shown in FIG. 3 as being according to Base64, any known method of encoding may be used as long as it suits the purposes of the techniques described herein. In this example, the payload identifies an issuer as “account.t-mobile.com,” a UUID as “U-96be1cf7-0f9f-450c-bdbe-11d6e12f9926” and a client public key. The signature 306 is created by signing the encoded header 302 and the encoded payload 304 with an identity provider private key 312 such as the IDP private key 230 of FIG. 2). The signature 306 is created using the digital signature algorithm identified in the header data 308 (e.g., HMAC SHA256, RSASSA-PSS, etc.). The signature 306 is used to verify that the sender of the token is who it claims it is, and to ensure that the message wasn't changed since originating from the sender].
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teaching of Seidman and Hires by incorporating “improved authentication token and usage”, as taught by Engan. One could have been motivated to do so in order for the client to provide an authorization token and a proof-of-possession (POP) token in the secure access request to a service provider. [ Engan, ¶15].
Regarding claim 17, Seidman, and Hires do not explicitly disclose, However, Engan discloses, wherein the base token is a signed base token which includes a signature.
[¶¶41-46, FIG. 3 depicts an authentication token 300 according to one or more implementations of the techniques described herein. The authentication token 300 is shown as a data structure having a format of a standard JSON Web Token (JWT), but other formats may be used without departing from the scope of the claims appended hereto. The authentication token 300 includes a header 302, a payload 304, and a signature 306. The header 302 includes header data 308 that is typically, but not necessarily, made up of two parts: a type of the token, and a digital signing algorithm used with the token (e.g., HMAC SHA256, RSASSA-PSS, etc.). The header data 308 is encoded using Base64, Base64url, or some other mutually recognized scheme to produce the header 302.In this example, the header indicates that the token type is a JSON Web Token, and that the PS256 algorithm was used with the token. The payload 304 (sometimes referred to as a “body”), includes statements about an entity and may contain additional data. In the example provided, the payload 304 includes at least a client public key 310 (similar to the client public key 228 of FIG. 2) and a unique user identifier (UUID) associated with the client device 202 (FIG. 2). Typically, the payload 304 will also contain other information, such as information that identifies an issuer of the token, a subject of the token, an expiration time of the token, etc. The client public key 310, and other data (if present), is encoded to produce the payload 304. Although such encoding is shown in FIG. 3 as being according to Base64, any known method of encoding may be used as long as it suits the purposes of the techniques described herein. In this example, the payload identifies an issuer as “account.t-mobile.com,” a UUID as “U-96be1cf7-0f9f-450c-bdbe-11d6e12f9926” and a client public key. The signature 306 is created by signing the encoded header 302 and the encoded payload 304 with an identity provider private key 312 such as the IDP private key 230 of FIG. 2). The signature 306 is created using the digital signature algorithm identified in the header data 308 (e.g., HMAC SHA256, RSASSA-PSS, etc.). The signature 306 is used to verify that the sender of the token is who it claims it is, and to ensure that the message wasn't changed since originating from the sender].
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teaching of Seidman and Hires by incorporating “improved authentication token and usage”, as taught by Engan. One could have been motivated to do so in order for the client to provide an authorization token and a proof-of-possession (POP) token in the secure access request to a service provider. [ Engan, ¶15].
Regarding claim 18, Seidman discloses, wherein the authorization service is apart of a collaboration platform, and wherein the sender system sends communications to a recipient system associated with the first user and a recipient system associated with the second user via the collaboration platform[ ¶23, Applications associated with an enterprise may also include applications that allow communication between people, for example, email, messaging, web meetings, and so on].
Regarding claim 19, this claim is interpreted and rejected for the same rational set forth in claim 1.
Regarding claim 20, wherein the base token comprises a third claim having a type and a value, and wherein the operations further comprise, with the authorization service: generating a transformation delta comprising a fourth claim, the fourth claim having a same type as the third claim and a different value than the third claim; and transmitting the transformation delta to the sender system; and with the sender system: receiving the transformation delta from the authorization service; altering the first authentication token by replacing the value of the third claim with the value of the fourth claim; and transmitting the altered first authentication token to the recipient system associated with the first user
Hires does not explicitly disclose; however, this claim is rejected with the combination of Seidman and Engan reference:
Seidman discloses: [¶49-54, The password request includes the authentication token, the authorization token, the public key, the fully qualified domain name (FQDN) or internet protocol (IP) address, and the certificate hash of the client 210… The username can be determined by the control plane 150 and can be based, for example, an email address associated with the user or a User Principal Name (UPN)] …. The password can be generated, for example, if the user does not already have a password or one is not assigned to the user account… encrypting the password].
Furthermore, Engan discloses [¶79, a server 504 (FIG. 5) running a secure service receives a request to access the secure service from a client device 502 at block 1002. The request includes an authentication token 512 and a POP token 514. In at least one implementation, the request is an HTTP request that includes the authentication token 512 and the POP token 514 in an authorization header, though other request formats may be used].
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teaching of Seidman and Hires by incorporating “improved authentication token and usage”, as taught by Engan. One could have been motivated to do so in order for the client to provide an authorization token and a proof-of-possession (POP) token in the secure access request to a service provider. [ Engan, ¶15].
Claim 7 is rejected under 35 U.S.C. 103 as being unpatentable over Seidman (US2024/0080200), and in view of Engan (US2019/0124070), and further in view of Hires (US2021/0141888), and further in view of Hussain (US11806241).
Regarding claim 7, Seidman, Engan, and Hires do not explicitly disclose, however Hussain discloses, wherein the type of the third claim and the fourth claim is scope (101) Authentication module 444 provides authentication management of patient-specific implant data to users (e.g., implant manufacturers, patients, family members, healthcare providers, approved users, etc.). Authentication module 444 can manage the access (e.g., read-only, editing capability, privacy protecting, etc.) to the implant data based on geolocation, biometrics, blockchain, token, or key functionality for user authentication. Authentication module 444 provides token functionality for user authentication to access the implant data (e.g., implant design files, fabrication instructions, etc.). Authentication module 444 can generate a token for the user to access the implant data. In some implementations, the token is valid for a threshold of time during which the user can access the implant data. A user can request and receive a token from the authentication module 444].
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teaching of Seidman, Engan and Hires by incorporating “authentication module generated token “, as taught by Hussain. One could have been motivated to do so in order for the authentication module to manage the access to the implant data and provide token functionality for user authentication to access the implant data [ Hussain, ¶101].
Claim 16 is rejected under 35 U.S.C. 103 as being unpatentable over Seidman (US2024/0080200), and in view of Engan (US2019/0124070), and further in view of Hires (US2021/0141888), and further in view of Xiong, Ping (CN 109040098 A), hereinafter, “Ping”.
Regarding claim 16, Seidman, Engan, and Hires do not explicitly disclose, however Ping discloses, wherein the base token is an unsigned base token which does not include a signature [ the JWT Token is mainly composed of head character string of the header, payload, visa supervisord….the Token generation device JWT is mainly composed of head header, payload payload, visa supervisord three parts; First, the header encryption for base64 forms the first part, then defining a payload, then the second part of the base64 encryption to obtain JWT, then the base64 the encrypted header and the encrypted payloads base64. form character string, then the secret combination encrypted by means of an encryption header in the declaration to the character string to form a third portion of the JWT, at last, the three parts. connecting to a complete character string to form the final JWT].
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teaching of Seidman, Engan, and Hires by incorporating “JWT Token composed of header, payload, surpervised”, as taught by Ping. One could have been motivated to do so in order for realizing MQTT protocol authentication based on JWT [ Ping, Abstract, invention content].
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
See submitted 892 for more relevant references.
Mossoba (US2022/0138736) [ claim 3. The method of claim 1, wherein the access to the email account is obtained based on a token received from an authentication server, wherein the token is associated with a type of access to the email account, and wherein the type of access is associated with at least one of: full access, read-only access, or access to emails that contain a particular characteristic.
LIN, Shao-Liu(CN 117375882 A) The invention claims an identity authentication method, system and electronic device of API gateway, the method comprises: the tenant application generates the request protection head and the effective load and uses the key to calculate the HMAC value; forming a request JSON with the HMAC value, the protection header and the payload, and sending an API gateway request to obtain an authorization token; judging the validity of the request JSON, forwarding the route to the route center; the authentication center finds the corresponding key according to the access key of the request JSON, calculates the HMAC value and compares the HMAC value with the previous value… the authentication center issues the authorization token to the API gateway, and the API gateway routes the authorization token to the tenant application; the tenant application submits the request data to access the upstream service after obtaining; checking the request data after the request data passes through the API gateway; the authentication token is verified after the upstream service is received, and the identity verification is finished after the verification is passed. The invention can reduce the delay of the request forwarding in the API gateway and improve the security of the private key and algorithm and the tenant service performance.
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to SHAHRIAR ZARRINEH whose telephone number is (571)272-1207. The examiner can normally be reached Monday-Friday, 8:30am-5:30pm.
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, Jorge Ortiz-Criado can be reached at 571-272-7624. 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.
/SHAHRIAR ZARRINEH/Primary Examiner, Art Unit 2496
Prosecution Insights