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 .
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 03/04/2026 has been entered.
Response to Amendments / Arguments
Regarding the rejection(s) of claims under 35 USC 103:
Applicant’s arguments, filed 03/04/2026, in view of the amended claims, have been fully considered and are partially persuasive.
Applicant argues that "Fryer's client application directly communicates with the IDP to obtain the encrypted access token and then directly sends resource requests including that token to a resource server" and that "there is no proxy associated with a message rendering environment that mediates this exchange."
In response, it is noted that Fryer at paragraph [0019] explicitly recites that "a user agent 222 is also provided in the memory 212 to handle authentication and authorization of a user account via communication with the IDP 204, such as by receiving and sending user account credentials to the IDP 204." The user agent 222 of Fryer accordingly operates as an intermediary component that receives user credentials and communicates with the IDP 204 to exchange those credentials for an authorization code, which is subsequently used to obtain the encrypted access token as described at paragraphs [0026]-[0028] of Fryer. This sequence of receiving credentials and exchanging them with an identification service to obtain a token constitutes the claimed proxy that exchanges user credentials for the second token. Furthermore, the claim recites only that the proxy be "associated with" the message rendering environment, not a structurally distinct network level intermediary. Fryer's user agent 222 is associated with the client application 224, which handles resource access and message rendering functionality.
Applicant argues that "the Examiner acknowledges that Fryer was not cited for the message rendering environment or common reusable component aspects, but rather for the token-based authentication architecture" and that this acknowledgment limits the combination such that it fails to teach the proxy architecture.
In response, it is noted that this argument mischaracterizes the basis of the rejection. Fryer was cited for the second token elements and the mapping of Fryer to those elements was intentional. Applicant's argument that limiting Fryer to the token elements somehow defeats the rejection is unpersuasive because the proxy architecture recited in the amended elements is taught by Fryer's user agent 222 as discussed above, which is itself part of Fryer's token-based authentication architecture. The fact that Fryer was not cited for the message rendering environment or common reusable component does not disclude Fryer's token architecture from teaching or suggesting the proxy mechanism through which the token exchange occurs.
Applicant argues that "even if one were motivated to add a second token to Ospina's system, there would be no reason, based on the cited art, to implement that token acquisition through a proxy that intercepts the first request, strips user credentials, and substitutes a privacy-preserving token, all within the context of a message rendering environment executing AMP markup" and that "the Examiner's generalized motivation to improve security does not fill the gap."
In response, it is noted that under KSR the motivation to combine Ospina and Fryer as stated in the Office Action (specifically to enhance the security and flexibility of the authentication process and to implement a more robust authentication system reducing the risk of unauthorized access) remains valid and applicable to the proxy architecture specifically. Accordingly, Applicant's argument that the motivation to combine is insufficient to support the proxy architecture is not persuasive.
However, applicants argument that Ospina does not teach “wherein the common reusable component comprises a widget or module embedded in the message using a markup language that executes within the message rendering environment to enable user interaction with content provided by the sender”. Is persuasive, therefore the rejection is withdrawn, however the rejection is further maintained under Craddock et al. (US 20110179362 A1).
DETAILED ACTION
This is a reply to the arguments filed on 08/14/2025, in which, claims 1-20 are pending. Claims 1, 8, and 15 are independent.
When making claim amendments, the applicant is encouraged to consider the references in their entireties, including those portions that have not been cited by the examiner and their equivalents as they may most broadly and appropriately apply to any particular anticipated claim amendments.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1, 5-7, 8, 12-14, 15, and 18-20 are rejected under 35 U.S.C. 103 as being unpatentable over Ospina et al. (US 20220129904 A1, referred to as Ospina), in view of Fryer et al. (US 20220217124 A1, referred to as Fryer) in further view of Craddock et al. (US 20110179362 A1, referred to as Craddock.)
In reference to claim 1, A method comprising: receiving a message sent by a sender to a user, the message including an embedded common reusable component configured to provide interactive functionality within the message and a first token associated with the user, the first token generated by the sender and specific to the user (Ospina: [0006] provides for a service system generating a push notification to send to the client device based on the third party notification. Ospina paragraph [0006] further provides for a resource identifier which serves as the claimed "first token". It is generated by the sender (the service system) and is specific to the user, as it encodes a session identifier for the user account. Ospina paragraph [0178] further provides for the client device receiving a push notification. Ospina paragraph [0064] further provides that the messages sent use security tokens to grant access to a user account. Ospina paragraph [0042] provides that the service system includes an authentication server which uses security tokens for authentication. Ospina paragraph [0060] further provides for a URI associated with the user that includes parameters such as account name, and client ID. Ospina paragraph [0189] further provides for action buttons to provide interactive functionality within the message.)
By executing code within a message rendering environment to dynamically update content displayed in the message without navigating away from the message (Ospina: [0038], [0122], [0148] and [0189] Provides for processing instructions within push notifications and updating displays without launching a separate app.)
Displaying the message and the common reusable component to the user (Ospina: [0006] provides for displaying a message and an interactive icon to a user. Ospina paragraph [0179] further provides for a graphical user interface that displays the notification information as well as the interactive icon.)
Receiving an input from the user corresponding to an interaction with the common reusable component (Ospina: [0006] provides for receiving an indication that the user interacted with the interactive icon. Ospina paragraph [0149] further provides for determining whether the user actuated the interactive elements. Ospina paragraph [0179] even further provides for determining whether the user interacted with the interactive elements.
Generating a first request in response to the input from the user, the first request including user credentials (Ospina: [0150] provides for after input from the user, device level authentication is performed which includes password, fingerprint, etc.)
Generating a second request based on the first request; transmitting the second request to the sender (Ospina: Fig. 12 [0179] provides that after device level authentication has been performed, the authentication request is sent to the service system.)
Receiving a response to the second request, the response including one of content or confirmation of an action performed by the sender based on the second request. (Ospina: [0180]-[0181] provides for after successful authentication of the client, the client receives a confirmation message and a GUI to display to the user of acknowledgement that the transaction has been approved.)
Capturing analytics data associated with the interaction within the message and transmitting the analytics data to the sender (Ospina: [0079], [0096], 0160]-[0161] and [0151] Provides for logging and storing interaction data.)
Ospina does not explicitly disclose, obtaining a second token from an identification service separate from the sender, the second token based on the user credentials and wherein the second request includes a second token, however, Fryer discloses:
Obtaining a second token from an identification service separate from the sender, the second token based on the user credentials and Wherein the second request includes a second token (Fryer: [0028] Provides for a second token, and it's obtained from the IDP (identification service) separate form the sender based on the previously validated user credentials.
Wherein a proxy associated with the message rendering environment requests the second token from the identification service by exchanging the user credentials for the second token (Fryer: [0019]-[0027] Provides for intermediary agent (user agent 222) that exchanges user credentials with the identity provider to obtain a token.)
Wherein the second request is generated by removing the user credentials from the first request and including the second token in place of the user credentials (Fryer: [0013] and [0035] Provides for substituting raw user credentials with an encrypted token so that credentials are no longer exposed in downstream communications.)
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 teachings of Ospina, which provides a method for secure interactive messaging and authentication using tokens, with the teachings of Fryer, which introduces the concept of obtaining a second token from a separate identification service based on user credentials. One of ordinary skill in the art would recognize the ability to incorporate Fryer's second token acquisition process into Ospina's authentication system to enhance the security and flexibility of the authentication process. One of ordinary skill in the art would be motivated to make this modification in order to implement a more robust multi-factor authentication system, reducing the risk of unauthorized access even if the initial token is compromised.
Ospina in view of Fryer does not explicitly teach wherein the common reusable component comprises a widget or module embedded in the message using a markup language that executes within the message rendering environment to enable user interaction with content provided by the sender. However, Craddock teaches: Wherein the common reusable component comprises a widget or module embedded in the message using a markup language that executes within the message rendering environment to enable user interaction with content provided by the sender (Craddock: [0043]-[0056] and [0095]-[0096] Provides for HTML/markup-based components (DIV sections with metadata) that execute within the mail user agent to enable interactive functionality.)
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 teachings of Ospina in view of Fryer, which together provide a method for secure interactive messaging with multi-token authentication through separate identification services, with the teachings of Craddock, which introduces markup language-based widgets that execute within the message rendering environment for user interaction. One of ordinary skill in the art would recognize the ability to incorporate Craddock's markup-based interactive component architecture into the combined messaging and authentication system to provide standardized, portable interactive elements. One of ordinary skill in the art would be motivated to make this modification in order to allow reusable widget components to be embedded consistently across different messaging contexts.
In reference to claim 5, The method of claim 1, wherein the second token is also based on a device identification of a device of the user (Fryer: [0033] Provides for that the encrypted access token (second token) can be based on an identifier of the client device.)
In reference to claim 6, The method of claim 1, where in the second token is a time limited third-party token encrypted using JSON Web Encryption (JWE) (Fryer: [0034] Provides for using JWE for the encrypted access token (second token).)
In reference to claim 7, The method of claim 1, wherein generating the second request based on the first request comprises removing the user credentials from the first request (Ospina: [0150] provides that generating the second request does not include the authentication data (e.g. fingerprint) when being sent to the authentication server.)
In reference to claim 8, A non-transitory computer-readable storage medium, the computer-readable storage medium including instructions that when executed by a computing device, cause the computing device to: receive a message sent by a sender to a user, the message including an embedded common reusable component configured to provide interactive functionality within the message and a first token associated with the user, the first token generated by the sender and specific to the user (Ospina: [0006] provides for a service system generating a push notification to send to the client device based on the third party notification. Ospina paragraph [0006] further provides for a resource identifier which serves as the claimed "first token". It is generated by the sender (the service system) and is specific to the user, as it encodes a session identifier for the user account. Ospina paragraph [0178] further provides for the client device receiving a push notification. Ospina paragraph [0064] further provides that the messages sent use security tokens to grant access to a user account. Ospina paragraph [0042] provides that the service system includes an authentication server which uses security tokens for authentication. Ospina paragraph [0060] further provides for a URI associated with the user that includes parameters such as account name, and client ID. Ospina paragraph [0189] further provides for action buttons to provide interactive functionality within the message.)
By executing code within a message rendering environment to dynamically update content displayed in the message without navigating away from the message (Ospina: [0038], [0122], [0148] and [0189] Provides for processing instructions within push notifications and updating displays without launching a separate app.)
Display the message and the common reusable component to the user (Ospina: [0006] provides for displaying a message and an interactive icon to a user. Ospina paragraph [0179] further provides for a graphical user interface that displays the notification information as well as the interactive icon.)
Receive an input from the user corresponding to an interaction with the common reusable component (Ospina: [0006] provides for receiving an indication that the user interacted with the interactive icon. Ospina paragraph [0149] further provides for determining whether the user actuated the interactive elements. Ospina paragraph [0179] even further provides for determining whether the user interacted with the interactive elements.
Generate a first request in response to the input from the user, the first request including user credentials (Ospina: [0150] provides for after input from the user, device level authentication is performed which includes password, fingerprint, etc.)
Generate a second request based on the first request; transmitting the second request to the sender (Ospina: Fig. 12 [0179] provides that after device level authentication has been performed, the authentication request is sent to the service system.)
Receive a response to the second request, the response including one of content or confirmation of an action performed by the sender based on the second request. (Ospina: [0180]-[0181] provides for after successful authentication of the client, the client receives a confirmation message and a GUI to display to the user of acknowledgement that the transaction has been approved.)
Capturing analytics data associated with the interaction within the message and transmitting the analytics data to the sender (Ospina: [0079], [0096], 0160]-[0161] and [0151] Provides for logging and storing interaction data.)
Ospina does not explicitly disclose, obtaining a second token from an identification service separate from the sender, the second token based on the user credentials and wherein the second request includes a second token, however, Fryer discloses:
Obtaining a second token from an identification service separate from the sender, the second token based on the user credentials and Wherein the second request includes a second token (Fryer: [0028] Provides for a second token, and it's obtained from the IDP (identification service) separate form the sender based on the previously validated user credentials.
Wherein a proxy associated with the message rendering environment requests the second token from the identification service by exchanging the user credentials for the second token (Fryer: [0019]-[0027] Provides for intermediary agent (user agent 222) that exchanges user credentials with the identity provider to obtain a token.)
Wherein the second request is generated by removing the user credentials from the first request and including the second token in place of the user credentials (Fryer: [0013] and [0035] Provides for substituting raw user credentials with an encrypted token so that credentials are no longer exposed in downstream communications.)
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 teachings of Ospina, which provides a method for secure interactive messaging and authentication using tokens, with the teachings of Fryer, which introduces the concept of obtaining a second token from a separate identification service based on user credentials. One of ordinary skill in the art would recognize the ability to incorporate Fryer's second token acquisition process into Ospina's authentication system to enhance the security and flexibility of the authentication process. One of ordinary skill in the art would be motivated to make this modification in order to implement a more robust multi-factor authentication system, reducing the risk of unauthorized access even if the initial token is compromised.
Ospina in view of Fryer does not explicitly teach wherein the common reusable component comprises a widget or module embedded in the message using a markup language that executes within the message rendering environment to enable user interaction with content provided by the sender. However, Craddock teaches: Wherein the common reusable component comprises a widget or module embedded in the message using a markup language that executes within the message rendering environment to enable user interaction with content provided by the sender (Craddock: [0043]-[0056] and [0095]-[0096] Provides for HTML/markup-based components (DIV sections with metadata) that execute within the mail user agent to enable interactive functionality.)
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 teachings of Ospina in view of Fryer, which together provide a method for secure interactive messaging with multi-token authentication through separate identification services, with the teachings of Craddock, which introduces markup language-based widgets that execute within the message rendering environment for user interaction. One of ordinary skill in the art would recognize the ability to incorporate Craddock's markup-based interactive component architecture into the combined messaging and authentication system to provide standardized, portable interactive elements. One of ordinary skill in the art would be motivated to make this modification in order to allow reusable widget components to be embedded consistently across different messaging contexts.
In reference to claim 12, The computer-readable storage medium of claim 8, wherein the second token is also based on a device identification of the computing device of the user (Fryer: [0033] Provides for that the encrypted access token (second token) can be based on an identifier of the client device.)
In reference to claim 13, The computer-readable storage medium of claim 8, where in the second token is a time limited third party token encrypted using JSON Web Encryption (JWE). (Fryer: [0034] Provides for using JWE for the encrypted access token (second token).)
In reference to claim 14, The computer-readable storage medium of claim 8, wherein the instructions further configure the computing device to generate the second request based on the first request by removing the user credentials from the first request (Ospina: [0150] provides that generating the second request does not include the authentication data (e.g. fingerprint) when being sent to the authentication server.)
In reference to claim 15, A computing device comprising: a processor configured to: receive a message sent by a sender to a user, the message including an embedded common reusable component configured to provide interactive functionality within the message and a first token associated with the user, the first token generated by the sender and specific to the user (Ospina: [0006] provides for a service system generating a push notification to send to the client device based on the third party notification. Ospina paragraph [0006] further provides for a resource identifier which serves as the claimed "first token". It is generated by the sender (the service system) and is specific to the user, as it encodes a session identifier for the user account. Ospina paragraph [0178] further provides for the client device receiving a push notification. Ospina paragraph [0064] further provides that the messages sent use security tokens to grant access to a user account. Ospina paragraph [0042] provides that the service system includes an authentication server which uses security tokens for authentication. Ospina paragraph [0060] further provides for a URI associated with the user that includes parameters such as account name, and client ID. Ospina paragraph [0189] further provides for action buttons to provide interactive functionality within the message.)
By executing code within a message rendering environment to dynamically update content displayed in the message without navigating away from the message (Ospina: [0038], [0122], [0148] and [0189] Provides for processing instructions within push notifications and updating displays without launching a separate app.)
Display the message and the common reusable component to the user (Ospina: [0006] provides for displaying a message and an interactive icon to a user. Ospina paragraph [0179] further provides for a graphical user interface that displays the notification information as well as the interactive icon.)
Receive an input from the user corresponding to an interaction with the common reusable component (Ospina: [0006] provides for receiving an indication that the user interacted with the interactive icon. Ospina paragraph [0149] further provides for determining whether the user actuated the interactive elements. Ospina paragraph [0179] even further provides for determining whether the user interacted with the interactive elements.
Generate a first request in response to the input from the user, the first request including user credentials (Ospina: [0150] provides for after input from the user, device level authentication is performed which includes password, fingerprint, etc.)
Generate a second request based on the first request; transmitting the second request to the sender (Ospina: Fig. 12 [0179] provides that after device level authentication has been performed, the authentication request is sent to the service system.)
Receive a response to the second request, the response including one of content or confirmation of an action performed by the sender based on the second request. (Ospina: [0180]-[0181] provides for after successful authentication of the client, the client receives a confirmation message and a GUI to display to the user of acknowledgement that the transaction has been approved.)
Capturing analytics data associated with the interaction within the message and transmitting the analytics data to the sender (Ospina: [0079], [0096], 0160]-[0161] and [0151] Provides for logging and storing interaction data.)
Ospina does not explicitly disclose, obtaining a second token from an identification service separate from the sender, the second token based on the user credentials and wherein the second request includes a second token, however, Fryer discloses:
Obtaining a second token from an identification service separate from the sender, the second token based on the user credentials and Wherein the second request includes a second token (Fryer: [0028] Provides for a second token, and it's obtained from the IDP (identification service) separate form the sender based on the previously validated user credentials.
Wherein a proxy associated with the message rendering environment requests the second token from the identification service by exchanging the user credentials for the second token (Fryer: [0019]-[0027] Provides for intermediary agent (user agent 222) that exchanges user credentials with the identity provider to obtain a token.)
Wherein the second request is generated by removing the user credentials from the first request and including the second token in place of the user credentials (Fryer: [0013] and [0035] Provides for substituting raw user credentials with an encrypted token so that credentials are no longer exposed in downstream communications.)
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 teachings of Ospina, which provides a method for secure interactive messaging and authentication using tokens, with the teachings of Fryer, which introduces the concept of obtaining a second token from a separate identification service based on user credentials. One of ordinary skill in the art would recognize the ability to incorporate Fryer's second token acquisition process into Ospina's authentication system to enhance the security and flexibility of the authentication process. One of ordinary skill in the art would be motivated to make this modification in order to implement a more robust multi-factor authentication system, reducing the risk of unauthorized access even if the initial token is compromised.
Ospina in view of Fryer does not explicitly teach wherein the common reusable component comprises a widget or module embedded in the message using a markup language that executes within the message rendering environment to enable user interaction with content provided by the sender. However, Craddock teaches: Wherein the common reusable component comprises a widget or module embedded in the message using a markup language that executes within the message rendering environment to enable user interaction with content provided by the sender (Craddock: [0043]-[0056] and [0095]-[0096] Provides for HTML/markup-based components (DIV sections with metadata) that execute within the mail user agent to enable interactive functionality.)
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 teachings of Ospina in view of Fryer, which together provide a method for secure interactive messaging with multi-token authentication through separate identification services, with the teachings of Craddock, which introduces markup language-based widgets that execute within the message rendering environment for user interaction. One of ordinary skill in the art would recognize the ability to incorporate Craddock's markup-based interactive component architecture into the combined messaging and authentication system to provide standardized, portable interactive elements. One of ordinary skill in the art would be motivated to make this modification in order to allow reusable widget components to be embedded consistently across different messaging contexts.
In reference to claim 18, The computing device of claim 15, wherein the second token is also based on a device identification of the computing device of the user (Fryer: [0033] Provides for that the encrypted access token (second token) can be based on an identifier of the client device.)
In reference to claim 19, The computing device of claim 15, where in the second token is a time limited third party token encrypted using JSON Web Encryption (JWE). (Fryer: [0034] Provides for using JWE for the encrypted access token (second token).)
In reference to claim 20, The computing device of claim 15, wherein generating the second request based on the first request comprises removing the user credentials from the first request (Ospina: [0150] provides that generating the second request does not include the authentication data (e.g. fingerprint) when being sent to the authentication server.)
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 2 and 9 are rejected under 35 U.S.C. 103 as being unpatentable over Ospina et al. (US 20220129904 A1, referred to as Ospina), in view of Fryer et al. (US 20220217124 A1, referred to as Fryer) in further view of Craddock et al. (US 20110179362 A1, referred to as Craddock.) in further view of Bahety (US 11463258 B2, referred to as Bahety).
In reference to claim 2, Ospina in view of Fryer discloses the method of Claim 1, wherein a service system receives a message with a common reusable component and a security token, displays the message, and responds to user interactions by generating requests that include user credentials and transmitting these requests for authentication. This system enhances security and user interaction efficiency.
Ospina in view of Fryer does not explicitly disclose the first token as an access token generated by the sender, however, Bahety discloses:
The method of claim 1, wherein the first token is an access token generated by the sender (Bahety: (Col. 1 Lines 25 - 58) and (Col. 2 Lines 10 - 25) provides for access tokens that are generated by a server and sent to a client. Bahety paragraph (Col. 6 Lines 27 - 45) further provides for sending a first access token to a client.)
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 teachings of Ospina in view of Fryer, which involve sending messages that include security tokens for user authentication and interaction, with the teachings of Bahety, who provides for access tokens that are generated by a server and sent to a client. One of ordinary skill in the art would recognize the ability to specifically utilize access tokens as the security tokens in the system taught by Ospina in view of Fryer. One of ordinary skill in the art would be motivated to make this modification in order to leverage the established utility of access tokens in securely managing user access to services, thus enhancing the security framework of the system.
In reference to claim 9, Ospina in view of Fryer discloses the method of Claim 8, wherein a service system receives a message with a common reusable component and a security token, displays the message, and responds to user interactions by generating requests that include user credentials and transmitting these requests for authentication. This system enhances security and user interaction efficiency.
Ospina in view of Fryer does not explicitly disclose the first token as an access token generated by the sender, however, Bahety discloses:
The computer-readable storage medium of claim 8, wherein the first token is an access token generated by the sender (Bahety: (Col. 1 Lines 25 - 58) and (Col. 2 Lines 10 - 25) provides for access tokens that are generated by a server and sent to a client. Bahety paragraph (Col. 6 Lines 27 - 45) further provides for sending a first access token to a client.)
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 teachings of Ospina in view of Fryer, which involve sending messages that include security tokens for user authentication and interaction, with the teachings of Bahety, who provides for access tokens that are generated by a server and sent to a client. One of ordinary skill in the art would recognize the ability to specifically utilize access tokens as the security tokens in the system taught by Ospina in view of Fryer. One of ordinary skill in the art would be motivated to make this modification in order to leverage the established utility of access tokens in securely managing user access to services, thus enhancing the security framework of the system.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 3, 10, and 16 are rejected under 35 U.S.C. 103 as being unpatentable over Ospina et al. (US 20220129904 A1, referred to as Ospina), in view of Fryer et al. (US 20220217124 A1, referred to as Fryer) in further view of Craddock et al. (US 20110179362 A1, referred to as Craddock.) in further view of Amp.Dev (“Amp-Form”, referred to as Amp.Dev).
In reference to claim 3, Ospina in view of Fryer discloses the method of Claim 1, wherein a service system receives a message with a common reusable component and a security token, displays the message, and responds to user interactions by generating requests that include user credentials and transmitting these requests for authentication. This system enhances security and user interaction efficiency.
Ospina in view of Fryer does not explicitly disclose the message further includes an AMP XHR URL, and the first request and the second request include the AMP XHR URL, however, Amp.Dev discloses:
The method of claim 1, wherein the message further includes an AMP XHR URL, and the first request and the second request include the AMP XHR URL (Amp.Dev: “Introduction” and “Form Verification” that the amp-form extension supports forms and input fields in an AMP document, allowing both HTTP and XHR submissions. It specifically discusses the use of an XHR URL for form submissions without requiring a page reload, and its verification process involves sending form fields to a verify-xhr URL for server-side validation.) 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 teachings of Ospina in view of Fryer, which involves secure message transmissions and user interactions, with the teachings of Amp.Dev, which provides for the integration of XHR URLs for form validation and submission without page reloads. One of ordinary skill in the art would recognize the ability to incorporate XHR URLs into the system to streamline user interactions and enhance the functionality of web forms by using asynchronous validation. One of ordinary skill in the art would be motivated to make this modification in order to improve user experience and system responsiveness by reducing page reloads and providing immediate feedback on form submissions.
In reference to claim 10, Ospina in view of Fryer discloses the method of Claim 8, wherein a service system receives a message with a common reusable component and a security token, displays the message, and responds to user interactions by generating requests that include user credentials and transmitting these requests for authentication. This system enhances security and user interaction efficiency.
Ospina in view of Fryer does not explicitly disclose the message further includes an AMP XHR URL, and the first request and the second request include the AMP XHR URL, however, Amp.Dev discloses:
The computer-readable storage medium of claim 8, wherein the message further includes an AMP XHR URL, and the first request and the second request include the AMP XHR URL (Amp.Dev: “Introduction” and “Form Verification” that the amp-form extension supports forms and input fields in an AMP document, allowing both HTTP and XHR submissions. It specifically discusses the use of an XHR URL for form submissions without requiring a page reload, and its verification process involves sending form fields to a verify-xhr URL for server-side validation.) 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 teachings of Ospina in view of Fryer, which involves secure message transmissions and user interactions, with the teachings of Amp.Dev, which provides for the integration of XHR URLs for form validation and submission without page reloads. One of ordinary skill in the art would recognize the ability to incorporate XHR URLs into the system to streamline user interactions and enhance the functionality of web forms by using asynchronous validation. One of ordinary skill in the art would be motivated to make this modification in order to improve user experience and system responsiveness by reducing page reloads and providing immediate feedback on form submissions.
In reference to claim 16, Ospina in view of Fryer discloses the method of Claim 15, wherein a service system receives a message with a common reusable component and a security token, displays the message, and responds to user interactions by generating requests that include user credentials and transmitting these requests for authentication. This system enhances security and user interaction efficiency.
Ospina in view of Fryer does not explicitly disclose the message further includes an AMP XHR URL, and the first request and the second request include the AMP XHR URL, however, Amp.Dev discloses:
The computing device of claim 15, wherein the message further includes an AMP XHR URL, and the first request and the second request include the AMP XHR URL (Amp.Dev: “Introduction” and “Form Verification” that the amp-form extension supports forms and input fields in an AMP document, allowing both HTTP and XHR submissions. It specifically discusses the use of an XHR URL for form submissions without requiring a page reload, and its verification process involves sending form fields to a verify-xhr URL for server-side validation.) 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 teachings of Ospina in view of Fryer, which involves secure message transmissions and user interactions, with the teachings of Amp.Dev, which provides for the integration of XHR URLs for form validation and submission without page reloads. One of ordinary skill in the art would recognize the ability to incorporate XHR URLs into the system to streamline user interactions and enhance the functionality of web forms by using asynchronous validation. One of ordinary skill in the art would be motivated to make this modification in order to improve user experience and system responsiveness by reducing page reloads and providing immediate feedback on form submissions.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 4, 11, and 17 are rejected under 35 U.S.C. 103 as being unpatentable over Ospina et al. (US 20220129904 A1, referred to as Ospina), in view of Fryer et al. (US 20220217124 A1, referred to as Fryer) in further view of Craddock et al. (US 20110179362 A1, referred to as Craddock.) in further view of Amp.Dev (“Amp-Form”, referred to as Amp.Dev) in even further view of Dudley et al. (US 10635792 B2, referred to as Dudley).
In reference to claim 4, Ospina in view of Fryer in further view of Amp.Dev discloses the method of Claim 3, wherein a service system receives a message including an AMP XHR URL and processes requests that incorporate this URL to enhance interactions without page reloads, based on secure and authenticated user inputs.
Ospina in view of Fryer in further view of Amp.Dev does not explicitly disclose the authentication of the AMP XHR URL, however, Dudley discloses:
The method of claim 3, further comprising authenticating the AMP XHR URL (Dudley: (Col.5 Lines 14 - 36) and (Col. 6 Lines 29 - 40) provides for an authentication code generator that utilizes a hashing algorithm to receive authentication parameters such as a user’s phone number, identifier, and timestamp to generate a unique or practically unique hashed value, which is then used by a URL generator to create a unique, parameterized URL. This URL is subsequently validated against the original authentication parameters.)
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 teachings of Ospina in view of Fryer in view of Amp.Dev, which involve managing and incorporating XHR URLs in web communications, with the teachings of Dudley, which detail the creation and validation of unique URLs based on hashed authentication parameters. One of ordinary skill in the art would recognize the ability to apply Dudley’s method of URL authentication to the AMP XHR URLs used in the system taught by Ospina, Fryer, and Amp.Dev. One of ordinary skill in the art would be motivated to make this modification in order to ensure the security and integrity of communications, particularly when handling sensitive form data or user interactions over the web.
In reference to claim 11, Ospina in view of Fryer in further view of Amp.Dev discloses the method of Claim 10, wherein a service system receives a message including an AMP XHR URL and processes requests that incorporate this URL to enhance interactions without page reloads, based on secure and authenticated user inputs.
Ospina in view of Fryer in further view of Amp.Dev does not explicitly disclose the authentication of the AMP XHR URL, however, Dudley discloses:
The computer-readable storage medium of claim 10, wherein the instructions further configure the computing device to validate the AMP XHR URL (Dudley: (Col.5 Lines 14 - 36) and (Col. 6 Lines 29 - 40) provides for an authentication code generator that utilizes a hashing algorithm to receive authentication parameters such as a user’s phone number, identifier, and timestamp to generate a unique or practically unique hashed value, which is then used by a URL generator to create a unique, parameterized URL. This URL is subsequently validated against the original authentication parameters.)
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 teachings of Ospina in view of Fryer in view of Amp.Dev, which involve managing and incorporating XHR URLs in web communications, with the teachings of Dudley, which detail the creation and validation of unique URLs based on hashed authentication parameters. One of ordinary skill in the art would recognize the ability to apply Dudley’s method of URL authentication to the AMP XHR URLs used in the system taught by Ospina, Fryer, and Amp.Dev. One of ordinary skill in the art would be motivated to make this modification in order to ensure the security and integrity of communications, particularly when handling sensitive form data or user interactions over the web.
In reference to claim 17, Ospina in view of Fryer in further view of Amp.Dev discloses the method of Claim 16, wherein a service system receives a message including an AMP XHR URL and processes requests that incorporate this URL to enhance interactions without page reloads, based on secure and authenticated user inputs.
Ospina in view of Fryer in further view of Amp.Dev does not explicitly disclose the authentication of the AMP XHR URL, however, Dudley discloses:
The computing device of claim 16, wherein the processor is further configured to validate
the AMP XHR URL (Dudley: (Col.5 Lines 14 - 36) and (Col. 6 Lines 29 - 40) provides for an authentication code generator that utilizes a hashing algorithm to receive authentication parameters such as a user’s phone number, identifier, and timestamp to generate a unique or practically unique hashed value, which is then used by a URL generator to create a unique, parameterized URL. This URL is subsequently validated against the original authentication parameters.)
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 teachings of Ospina in view of Fryer in view of Amp.Dev, which involve managing and incorporating XHR URLs in web communications, with the teachings of Dudley, which detail the creation and validation of unique URLs based on hashed authentication parameters. One of ordinary skill in the art would recognize the ability to apply Dudley’s method of URL authentication to the AMP XHR URLs used in the system taught by Ospina, Fryer, and Amp.Dev. One of ordinary skill in the art would be motivated to make this modification in order to ensure the security and integrity of communications, particularly when handling sensitive form data or user interactions over the web.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. See PTO-892.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to AIDAN EDWARD SHAUGHNESSY whose telephone number is (703)756-1423. The examiner can normally be reached on Monday-Friday from 7:30am to 5pm.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Jeffrey Nickerson, can be reached at telephone number (469) 295-9235. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from Patent Center and the Private Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from Patent Center or Private PAIR. Status information for unpublished applications is available through Patent Center and Private PAIR for authorized users only. Should you have questions about access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free).
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) Form at https://www.uspto.gov/patents/usptoautomated-interview-request-air-form.
/A.E.S./Examiner, Art Unit 2432
/Jeffrey Nickerson/Supervisory Patent Examiner, Art Unit 2432