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 .
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 January 12th 2026 has been entered.
Response to Amendment
3. The Amendment filed on January 12th 2026 has been entered. Claims 32 and 33 are newly added and claims 1 – 10 and 22 – 33 are currently pending.
Response to Arguments
35 U.S.C. §103
4. Applicant's arguments, see Remarks pp. 5 -8, filed January 12th 2026, with
respect to the rejections of claims1 – 10 and 22 – 31 under 35 U.S.C. §103 have been fully considered but they are persuasive.
The crux of applicant’s arguments is that the cited art does not teach the claimed invention. In particular, applicant argues that the Lawrence reference does not teach a token that includes a physical lor digital device that provides two-factor authentication as claimed.
Examiner respectfully agrees
Applicant further argues that cited art does not teach such systems and methods as clamed let alone recognize the foregoing problem with traditional ETL processes.
Examiner respectfully agrees
Upon further consideration of applicant’s arguments, pertinent art from an exhaustive search has been found in Verma et al. (United States Patent Publication Number 2023/0169085 ), in view of Bahrami et al. (United States Patent Publication Number 2021/0067337), hereinafter referred to as Bahrami and in further view of Sathyanarayana, et al. (United States Patent Publication Number 20240275598) hereinafter Sathyanarayana, Li et al., (United States Patent Publication Number 20180365305 ) hereinafter Li and Harris et al. (United States Patent Publication Number 20210083873) hereinafter Harris that teach applicant’s claimed invention.
Claim Rejections – 35 U.S.C. §103
5. 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.
6. 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:
a. Determining the scope and contents of the prior art
b. Ascertaining the differences between the prior art and the claims at issue
c. Resolving the level of ordinary skill in the pertinent art
d. Considering objective evidence present in the application indicating
obviousness or nonobviousness
Claims 1, 2, 4, 6 - 8, 22, 23, 25 and 27 - 29 are rejected under 35 U.S.C. 103 as being unpatentable over Verma et al. (United States Patent Publication Number 2023/0169085 ), in view of Bahrami et al. (United States Patent Publication Number 2021/0067337), hereinafter referred to as Bahrami and in further view of Sathyanarayana, et al. (United States Patent Publication Number 20240275598) hereinafter Sathyanarayana
Regarding claim 1 Verma teaches a system for processing a plurality of extract transform load (ETL) jobs (user codes executed as multiple directed acyclic graphs [0018], [0020], Generally, the user code 104 may be a code artifact that defines a process for extracting data from a data repository, processing the data (e.g., transforming the extracted data from one format to another format), and loading the processed data into another process [0022]) between an application (ABS., ETL system) (ETL system [0018]) and a server, (using AWS™, these resources may include and are not limited to EC2™, S3™, LAMBDA™, SAGEMAKER ™, and other available resources. [0024]) comprising: at least one memory storing instructions; (process computer-executable instructions, e.g., stored in memory 608 [0053]) and at least one processor (Processing system 600 includes a central processing unit (CPU) 602 [0053]) of the server (using AWS™, these resources may include and are not limited to EC2™, S3™, LAMBDA™, SAGEMAKER ™, and other available resources. [0024]) configured to execute the instructions to: (capable of executing computer-executable instructions. [0053]) wherein the processor (Processing system 600 includes a central processing unit (CPU) 602 [0053]) utilizes the token to authenticate (user code authentication token [0043]) the application's access to the API; (When user code 104 is uploaded to DAG 138, plugin 142 makes an application program interface (API) call to the processing platform 120 for user authentication credentials 130 related to user code 104 [0025])
and receive a plurality of API calls (When user code 104 is uploaded to DAG 138,
plugin 142 makes an application program interface (API) call to the processing platform 120 … context validation component 150 also validates the user authentication credentials 130 with an API call to the authorization component 128, [0025]) associated with the ETL jobs, (user codes executed as multiple directed acyclic graphs [0018], [0020], Generally, the user code 104 may be a code artifact that defines a process for extracting data from a data repository, processing the data (e.g., transforming the extracted data from one format to another format), and loading the processed data into another process [0022])wherein each API call (When user code 104 is uploaded to DAG 138, plugin 142 makes an application program interface (API) call to the processing platform 120 … context validation component 150 also validates the user authentication credentials 130 with an API call to the authorization component 128, [0025]) includes security information (user authentication credentials [0025]) used to verify the API call, (context validation component 150 validates that the user code permissions 112 are the correct permissions for use with user code 104 embodied in the DAG 138 by verifying the unique identifier, [0025]) wherein the security information(user authentication credentials [0025]) includes confidential information, (user code permissions associated with the user code [0025]) and wherein the processor (Processing system 600 includes a central processing unit (CPU) 602 [0053]) utilizes the token (user code authentication token [0043]) and the security information (user authentication credentials [0025]) to determine permissions (Based on the user authentication credentials 130 and file name, user code permissions are provided to the plugin 142. The user code permissions are integrated into the DAG 138 as the context 140, for execution on the ETL engine 146. [0025]) for the use of the plurality of API calls (When user code 104 is uploaded to DAG 138, plugin 142 makes an application program interface (API) call to the processing platform 120 … context validation component 150 also validates the user authentication credentials 130 with an API call to the authorization component 128, [0025]) to run in real-time (In this context, an ETL system schedules operation of user code, and orchestrates execution of user code based on dependencies in user code upon other user code, data sources, and transactions occurring in other systems. [0024])
Verma does not fully disclose receive a token sent from the application, wherein the token is provided to the application by a token-based security system in response to receiving a token request associated with an application programming interface (API) call, receive a message header table including one or more message headers, wherein a message header of the one or more message headers contains the token; and wherein each API call contains a message header, and wherein the token includes a physical or digital device that provides two-factor authentication for a user or the application to prove the identity of the user or the application,
Bahrami teaches receive a token sent from the application, (the developer 410 may request an access token that may be included in a developed software program such that when the API is invoked, the access token is utilized and/or included in requests to the API provider when the developed software program is executing [0043]) wherein the token is provided to the application (developed software program [0043]) by a token-based security system (API provider 420 [0043]) in response to receiving a token request associated with an application programming interface (API) call, (At block 510, the developer 410 may submit a request to the API provider 420 requesting access to the APL [0043]) and wherein each API call contains a message header, (For example, the native API call may include a header 321 [0037])
It would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Verma to incorporate the teachings of Bahrami whereby receive a token sent from the application, wherein the token is provided to the application by a token-based security system in response to receiving a token request associated with an application programming interface (API) call, and wherein each API call contains a message header. By doing so input data from an application programming interface (API), and encrypting the input data for the API using a public key of a provider of the APL The method may also include transmitting, to an API management server, an API request that invokes the API, where the API request includes an API call for the API and the encrypted input data. Bahrami [0003]
Sathyanarayana teaches receive a message header table including one or more message headers, (The identifying information includes values of one or more request headers and/or other information derived via the Transmission Control Protocol and/or Internet Protocol ("TCP/IP") connection between the distribution platform 103 and client device 105. The request headers include standard HTTP request headers such as User-agent, Referrer, Authorization, etc., and/or custom headers such as Unique User Identifier ("UUI"), client device identifier, etc. [0021]) wherein a message header of the one or more message headers contains the token; (Stream service provider 101 also generates (at 104) a Unique User Identifier (UUI) based on the login credentials of the user and provides (at 106) it along with the signed access token in a separate header. [0016]) and wherein the token includes a physical or digital device that provides two-factor authentication for a user or the application to prove the identity of the user or the application, (In some embodiments, two-factor authentication and/or additional authentication operations may be performed to ensure that the login credentials of a particular user are being used by the particular user and not another user, and therefore prevent other users or client devices from using the login credentials of a particular user or client device 105. In some embodiments, authorizing (at 310) client device 105 includes obtaining an invitee list that is stored for the requested event, comparing a name and/or email address provided (at 308) by client device 105 against the invitee list, rejecting the request based on the provided (at 308) name and/or email address not being specified in the invitee list, and authorizing (at 310) client device 105 for access to the requested event based on the provided (at 308) name and/or email address being specified in the invitee list. [0040])
It would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Verma in view of Bahrami to incorporate the teachings of Sathyanarayana whereby receive a message header table including one or more message headers, wherein a message header of the one or more message headers contains the token; and wherein the token includes a physical or digital device that provides two-factor authentication for a user or the application to prove the identity of the user or the application. By doing so the identifying information included with the distribution platform authentication request (e.g., identifying information within the message header), and verifying that client device 105 was authorized for secure stream access by stream service provider 101. Sathyanarayana [0019]
Claim 22 corresponds to claim 1 and is rejected accordingly
Regarding claim 2 Verma in view of Bahrami and Sathyanarayana teaches the system of claim 1,
Verma as modified does not fully disclose wherein the token is provided to the application in a data response message.
Bahrami teaches wherein the token is provided to the application in a data response message (In these and other embodiments, the developer 410 may request an access token that may be included in a developed software program such that when the API is invoked, the access token is utilized and/or included in requests to the API provider when the developed software program is executing.) [0043].
It would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Verma in view of Sathyanarayana to incorporate the teachings of Bahrami wherein the token is provided to the application in a data response message. By doing so the developer 410 may provide the API access information (e.g., API authentication tokens, etc.) and encryption information (e.g., private key PRc and public key PKMa) as distinct components or credentials. Bahrami [0047]
Claim 23 corresponds to claim 2 and is rejected accordingly
Regarding claim 4 Verma in view of Bahrami and Sathyanarayana teaches the system of claim 1,
Verma as modified does not fully disclose wherein the processor receives the token as a header value in a data request message.
Sathyanarayana teaches wherein the processor receives the token as a header value (As shown in FIG. 3, access token 301 is a JavaScript Object Notation ("JSON") Web Token with a header, payload, and the encrypted signature. The header
identifies the signing algorithm, the access token type (e.g., JWT), and the client identifier token key identifier. [0048]) in a data request message (HTTP request [0021])
It would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Verma in view of Bahrami to incorporate the teachings of Sathyanarayana wherein the processor receives the token as a header value in a data request message. By doing so the unique user identifier is generated by stream service provider 101 based on the provided (at 308) login credentials and/or a combination of header values in the messaging received from client device 105. Sathyanarayana [0045]
Claim 25 corresponds to claim 4 and is rejected accordingly
Regarding claim 6 Verma in view of Bahrami and Sathyanarayana teaches the system of claim 1,
Verma as modified does not fully disclose wherein the token-based security system generates the token based on an Open Authorization (OAuth) protocol.
Bahrami teaches wherein the token-based security system (API provider 420 [0043]) generates the token based on an Open Authorization (OAuth) protocol (In these and other embodiments, the developer 410 may request an access
token that may be included in a developed software program such that when the API is invoked, the access token is utilized and/or included in requests to the API provider when the developed software program is executing. Additionally, or alternatively, any other type of API authentication approach may be utilized, such as a username/password, OAuth, 0Auth2, digest, etc. [0043]).
It would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Verma in view of Sathyanarayana to incorporate the teachings of Bahrami wherein the token-based security system generates the token based on an Open Authorization (OAuth) protocol. By doing so for hypertext transfer protocol (HTTP) authentication, a user name and password may be provided in the API request 160 to prove authenticity to the API provider 120. In such an example, the username and/or password may be included in
the encrypted portion 164. Other examples of authentication include API keys, open authentication (OAuth, including OAuth version 1.0, 2.0, etc.). Bahrami [0020]
Claim 27 corresponds to claim 6 and is rejected accordingly
Regarding claim 7 Verma in view of Bahrami and Sathyanarayana teaches the system of claim 1,
Verma as modified further teaches wherein the token is valid for a predetermined period of time (the user code authentication token comprising an expiration time [0043])
Claim 28 corresponds to claim 7 and is rejected accordingly
Regarding claim 8 Verma in view of Bahrami and Sathyanarayana teaches the system of claim 1,
Verma as modified does not fully disclose wherein the token request includes a client identifier
Bahrami teaches wherein the token request (At block 510, the developer 410 may submit a request to the API provider 420 requesting access to the APL [0043]) includes a client identifier (the unencrypted portion 210 may include a client identifier field 212, a provider identifier field 214, and/or an authorization information field 216. In some embodiments, the client identifier field 212 may include an identifier by which the device, component, system, software, etc. and/or user invoking the API (referred to
as the API client). [0030])
It would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Verma in view of Sathyanarayana to incorporate the teachings of Bahrami wherein the token request includes a client identifier. By doing so such an identifier may include an identifier
that is non-sensitive (e.g., it is not harmful to the API client for the client identifier to be observed by potentially malicious parties). The client identifier within the client
identifier field 212 may serve as an identifier or other location information for where the API response is to be sent. Examples of such identifiers may include an internet
protocol (IP) address, a media access control (MAC) address, a user name, etc. [0030]
Claim 29 corresponds to claim 8 and is rejected accordingly
Claims 3, 5, 24 and 26 are rejected under 35 U.S.C. 103 as being unpatentable over Verma et al. (United States Patent Publication Number 2023/0169085 ), in view of Bahrami et al. (United States Patent Publication Number 2021/0067337), hereinafter referred to as Bahrami in view of Sathyanarayana, et al. (United States Patent Publication Number 20240275598) hereinafter Sathyanarayana and in further view of Li et al., (United States Patent Publication Number 20180365305 ) hereinafter Li
Regarding claim 3 Verma in view of Bahrami and Sathyanarayana teaches the system of claim 2,
Verma as modified does not fully disclose wherein the data response message includes a representational state transfer (REST) response message.
Li teaches wherein the data response message (error message [0044]) includes a representational state transfer (REST) response message (REST responses [0018])
It would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Verma in view of Bahrami and Sathyanarayana to incorporate the teachings of Li wherein the data response message includes a representational state transfer (REST) response message. By doing so one or more representational state transfer (REST) requests based on the received one or more events, and receiving one or more REST responses. At least
one of the one or more REST responses is validated. Li [0006]
Claim 24 corresponds to claim 3 and is rejected accordingly
Regarding claim 5 Verma in view of Bahrami and Sathyanarayana teaches the system of claim 4,
Verma as modified does not fully disclose wherein the data request message includes a REST request message.
Li teaches wherein the data request message (data the REST request body is loaded [0043]) includes a REST request message (ABS., REST request) (REST request [0018])
It would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Verma in view of Bahrami and Sathyanarayana to incorporate the teachings of Li wherein the data request message includes a REST request message. By doing so one or more representational state transfer (REST) requests based on the received one or more events, and receiving one or more REST responses. At least one of the one or more REST responses is validated. Li [0006]
Claim 26 corresponds to claim 5 and is rejected accordingly
Claims 9, 10, 30 and 31 are rejected under 35 U.S.C. 103 as being unpatentable over Verma et al. (United States Patent Publication Number 2023/0169085 ), in view of Bahrami et al. (United States Patent Publication Number 2021/0067337), hereinafter referred to as Bahrami in view of Sathyanarayana, et al. (United States Patent Publication Number 20240275598) hereinafter Sathyanarayana and in further view of Harris et al. (United States Patent Publication Number 20210083873) hereinafter Harris
Regarding claim 9 Verma in view of Bahrami and Sathyanarayana teaches the system of claim 8,
Verma as modified does not fully disclose wherein the token request further includes a secret value, and the secret value is provided for an application associated with the API call.
Harris teaches wherein the token request (a first bearer token from an authentication server (e.g., by sending a refresh token request to the authentication server). [0015]) further includes a secret value, (Furthermore, the common secret value may be shared with the client device 102B so that the client device is capable of generating the one or more cryptographic keys [0034]) and the secret value ( the common secret value [0034]) is provided for an application associated with the API call (For example, the intent request 114 specifies an API call to obtain shipping address
from a database. As a result, the resource server 108B may only fulfill resource requests satisfying the condition ( e.g., API calls to obtain shipping addresses from a database). [0035])
It would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Verma in view of Bahrami and Sathyanarayana to incorporate the teachings of Harris wherein the token request further includes a secret value, and the secret value is provided for an application associated with the API call. By doing so a cryptography service
utilizes one or more non-secret parameters (e.g., bearer tokens, client identifiers, or resource identifiers) to derive one or more cryptographic keys from a common secret
value. Harris [0033]
Claim 30 corresponds to claim 9 and is rejected accordingly
Regarding claim 10 Verma in view of Bahrami, Sathyanarayana and Harris teaches the system of claim 9,
Verma as modified does not fully disclose wherein the processor validates the token request based on the client identifier and the secret value.
Harris teaches wherein the processor (one or more processors [0063]) validates the token request (the system executing the process 800 may verify and/or validate the information included in the resource request in parallel. [0073]) based on the client identifier (client identifier [0072]]) and the secret value (secret value [0033])
It would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Verma in view of Bahrami and Sathyanarayana to incorporate the teachings of Harris. By doing so the resource server 108B may transmit a verification request to the authorization server 106B to validate the second bearer token 122 while comparing the identifier of the protected resource 126 obtained from access key 116 and the resource request 124 to validate that the identifier of the protected resource 126 obtained from each location matches. Harris [0034]
Claim 31 corresponds to claim 10 and is rejected accordingly
Claims 32 and 33 are rejected under 35 U.S.C. 103 as being unpatentable over Verma et al. (United States Patent Publication Number 2023/0169085 ), in view of Bahrami et al. (United States Patent Publication Number 2021/0067337), hereinafter referred to as Bahrami in view of Sathyanarayana, et al. (United States Patent Publication Number 20240275598) hereinafter Sathyanarayana and in further view of Lores et al. (United States Patent Publication Number 2019/0306157) hereinafter Lores
Regarding claim 32 Verma in view of Bahrami and Sathyanarayana the system of claim 1,
Verma as modified does not fully disclose wherein real-time API operations take place within one second.
Lores teaches wherein real-time API operations take place within one second (the maximum duration of an operation invoked by a single call is one minute [0045])
It would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Verma in view of Bahrami and Sathyanarayana to incorporate the teachings of Lores wherein real-time API operations take place within one second. By doing so if each JWT should be useable for up to 5 client calls (0047] Based on these assumptions, authentication service
106 may set the expiration time to allow each JWT a lifetime of 5 minutes. In addition, the JWT cache may be configured to evict each cache entry after 4 minutes (to ensure that a cached JWT is not used to close to its expiration time). Lores [0046] – [0047]
Regarding claim 33 Verma in view of Bahrami and Sathyanarayana the system of claim 22,
Verma as modified does not fully disclose wherein real-time API operations take place within one second.
Lores teaches wherein real-time API operations take place within one second (the maximum duration of an operation invoked by a single call is one minute [0045])
It would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Verma in view of Bahrami and Sathyanarayana to incorporate the teachings of Lores wherein real-time API operations take place within one second. By doing so if each JWT should be useable for up to 5 client calls (0047] Based on these assumptions, authentication service
106 may set the expiration time to allow each JWT a lifetime of 5 minutes. In addition, the JWT cache may be configured to evict each cache entry after 4 minutes (to ensure that a cached JWT is not used to close to its expiration time). Lores [0046] – [0047]
Conclusion
7. The prior art made of record and not relied upon is considered pertinent to
applicant's disclosure.
Dania M. Triff (United States Patent Publication Number 2015/0026114) teaches “a Message header table 910 includes ID, message type, message ID, session ID,
and message version data. The remote user table 915 includes ID, user login, and user authenticator data [0105]”
8. Any inquiry concerning this communication or earlier communications from the
examiner should be directed to Kweku Halm whose telephone number is (469) 295-
9144. The examiner can normally be reached on 7:30AM - 5:30PM Mon - Thur. If
attempts to reach the examiner by telephone are unsuccessful, the examiner's
supervisor, Sanjiv Shah can be reached on (571) 272-4098. 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 the
Patent Application Information Retrieval (PAIR) system. Status information for published
applications may be obtained from either Private PAIR or Public PAIR. Status information
for unpublished applications is available through Private PAIR only. For more
information about the PAIR system, see http://pair-direct.uspto.gov. Should you have
questions on access to the Private PAIR system, contact the Electronic Business Center
(EBC) at 866-217-9197 (toll-free).
/KWEKU WILLIAM HALM/Examiner, Art Unit 2166
/SANJIV SHAH/Supervisory Patent Examiner, Art Unit 2166
Prosecution Insights