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 .
Response to Amendment
2. The Amendment filed on November 2, 2018 has been entered. Claims xxx have been amended and claims xxx have been cancelled. Claims xxx are currently pending.
Response to Arguments
35 U.S.C. §103
3. Applicant's arguments, see Remarks pp. 7 -9, filed 08/03/2026, with
respect to the rejections of claims 1-10 and 22-33 under 35 U.S.C. §103 have been fully
considered and they are persuasive in part and non-persuasive in part
Applicant argues that the Verma reference does not provide a two-factor authentication and that it’s not cured by the Bahrami and Sathyanarayan references.
Examiner respectfully submits that although the Verma reference does not provide the two-factor authentication, Bharami teaches a two-factor authentication in paragraph [0040] “… 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…”
Next applicant argues that the amended limitations are not taught by the art of record
Examiner respectfully agrees.
Upon further consideration new grounds of rejection have been necessitated due
to Applicant's amendments and are made in view of Bykampadi et al., (United States Patent Publication Number 20190251241) hereinafter Bykampadi
Claim Rejections – 35 U.S.C. §103
4. 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.
5. 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 in view of Sathyanarayana, et al. (United States Patent Publication Number 20240275598) hereinafter Sathyanarayana and in further view of Bykampadi et al., (United States Patent Publication Number 20190251241) hereinafter Bykampadi
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, wherein the token further includes grant parameters based on authentication, the grant parameters configured to grant or limit access to 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]
Bykampadi teaches wherein the token (access tokens created from JavaScript Object Notation (]SON) Web Tokens (JWTs) [0055]) further includes grant parameters based on authentication, (bearer schema in the authorization header [0059]) the grant parameters (bearer schema [0059]) configured to grant or limit access (The claims in the JWT contain information required for the API resource server 406 to identify the client 402, scope of access, duration, etc. [0059], (e.g., the scope in the access token). [0094]) to the application (a specific service on the NF Service Producer 406 [0093])
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 Bykampadi wherein the token further includes grant parameters based on authentication, the grant parameters configured to grant or limit access to the application. By doing so the parameters included in the API include the access_token, along with the NF Service Consumer 402 instance id. The instance id must match what is included in the "subject" claim of the access token. Bykampadi [0093]
Claim 22 corresponds to claim 1 and is rejected accordingly
Regarding claim 2 Verma in view of Bahrami, Sathyanarayana and Bykampadi 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 and Bykampadi 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 , Sathyanarayana and Bykampadi 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 and Bykampadi 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, Sathyanarayana and Bykampadi 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 and Bykampadi 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, Sathyanarayana and Bykampadi 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 , Sathyanarayana and Bykampadi 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, and Bykampadi 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 in view of Bykampadi et al., (United States Patent Publication Number 20190251241) hereinafter Bykampadi and in further view of Li et al., (United States Patent Publication Number 20180365305 ) hereinafter Li
Regarding claim 3 Verma in view of Bahrami, Sathyanarayana and Bykampadi 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, Sathyanarayana and Bykampadi 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, Sathyanarayana and Bykampadi 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, Sathyanarayana and Bykampadi 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 in view of Bykampadi et al., (United States Patent Publication Number 20190251241) hereinafter Bykampadi and in further view of Harris et al. (United States Patent Publication Number 20210083873) hereinafter Harris
Regarding claim 9 Verma in view of Bahrami, Sathyanarayana and Bykampadi 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, Sathyanarayana and Bykampadi 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, Bykampadi 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, Sathyanarayana and Bykampadi 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 in view of Bykampadi et al., (United States Patent Publication Number 20190251241) hereinafter Bykampadi 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, Sathyanarayana and Bykampadi 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, Sathyanarayana and Bykampadi 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, Sathyanarayana and Bykampadi 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, Sathyanarayana and Bykampadi 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
6. 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 extension fee 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 date of this
final action.
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.
7. 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 9:00AM - 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). If you would like assistance from a USPTO Customer
Service Representative or access to the automated information system, call 800-786-
9199 (IN USA OR CANADA) or 571-272-1000.
/KWEKU WILLIAM HALM/Examiner, Art Unit 2166
/SANJIV SHAH/Supervisory Patent Examiner, Art Unit 2166
