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 March 27, 2026 has been entered.
Claim Objections
The following is a quotation of 35 U.S.C. 112(d):
(d) REFERENCE IN DEPENDENT FORMS.—Subject to subsection (e), a claim in dependent form shall contain a reference to a claim previously set forth and then specify a further limitation of the subject matter claimed. A claim in dependent form shall be construed to incorporate by reference all the limitations of the claim to which it refers.
Claims 5, 12 and 19 are objected to because they do not depend on a claim previously set forth. Appropriate correction is required.
Response to Arguments
Applicant's arguments filed on March 27, 2026 have been fully considered but they are not persuasive.
Applicant asserts on page 3, “[n]othing in any of the cited references describes identifying replay data.”
The Examiner maintains that Krishnaiah does describe identifying replay data in paragraph [0017], “…collecting user data about past use of the communication module by the user. The authentication module may associate this past user data with processes used by the user concurrently with the user data (e.g., processes used when the user data was collected, active, and/or current). Thus, during future uses of the communication device and/or requests to access those processes, the authentication module may require user data to match the requirements (e.g. required user data/parameters) in the generated authentication profile in order for the user to access those processes)”.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, 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, 8, 15 and 22-24 are rejected under 35 U.S.C. 103 as being unpatentable over Sanjeevaiah Krishnaiah et al. (Krishnaiah) U.S. Pub. Number 2019/0364028 in view of Morrison U.S. Pub. Number 2019/0036878, and further in view of Liu et al U.S. Pub. Number US 2018/0189612.
Regarding claims 1 and 22; Krishnaiah discloses a system for protecting an application programming interface (API), comprising:
a memory (fig.1, para. [0022]); and
at least one hardware processor that is coupled to the memory and configured to at least:
receive a combined API message containing sensor data from an API client and an API message, wherein the sensor data includes at least one of accelerometer data, magnetic data, proximity data, touch pressure data, touch size data, and sound data (fig.1, para. [0045] service provider server… to provide features to service provider server… programmatic client applications for interfacing with appropriate application programming interfaces (APIs) over network 150; para. [0047] service provider server 140 includes at least one communication module 148 adapted to communicate communication device 110 and/or payment provider server 130 over network 150. In various embodiments, communication module 148 may comprise a DSL (e.g., Digital Subscriber Line) modem, a PSTN (Public Switched Telephone Network) modem, an Ethernet device, a broadband device, a satellite device and/or various other types of wired and/or wireless network communication devices including microwave, radio frequency (RF), and infrared (IR) communication devices; para. [0051] communication device 110 may include audio modules, such as a microphone and speaker, which may detect a user's voice, voice input, and/or environmental noise. Additionally, communication device 110 may detect user data through a biometric sensor 1006 and/or accelerometer 1008, including fingerprints, facial recognition information, heartbeat, motions, height, etc. Communication device 110 may detect ambient light levels, atmospheric pressure, humidity, etc., through environmental sensor 1010. Communication module 110 may also receive user data over a network connection or through short range wireless communications with a nearby device using communication module 1012);
classify the sensor data to identify replay data (See para. [0017] …collecting user data about past use of the communication module by the user. The authentication module may associate this past user data with processes used by the user concurrently with the user data (e.g., processes used when the user data was collected, active, and/or current). Thus, during future uses of the communication device and/or requests to access those processes, the authentication module may require user data to match the requirements (e.g. required user data/parameters) in the generated authentication profile in order for the user to access those processes);
determine that the API message is not to be blocked based on the classifying (para. [0018] establish each authentication module to authenticate a user using an authentication profile based on available user data according to multiple pathways in order to provide access to the associated processes. Each pathway may correspond to required user data by the pathway in the authentication profile in order to authenticate the user and may require different user data. For example, access to a payment module may require one of two different authentication pathways in an authentication profile); and
process the API message (para. [0060] one matching profile may correspond to a payment application executed by the communication device. Use of the payment application may be limited by the at least one matching profile. In various embodiments, the user may determine the authentication profiles based on requirements for device and application security).
Krishnaiah does not disclose, but Morrison discloses, separating the sensor data and the API message (Morrison: para. [0022] an “API request” can be any signaling occurring from a client computer to a computer server or other API endpoint that may be performed using a defined syntax and one or more parameters; para. [0026] client application generates (block 202) an API request containing a URL address for a resource that it desires to access through an API interface provided by the computer server 110. The URL address contains a URL key. The API security gateway 120 receives (block 204) the API request, and parses (block 206) the URL address to identify the URL key).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teaching of Krishnaiah to separate the sensor data and the API message, as taught by Morrison. The motivation would be to identify the message to prevent attempts to misuse/attack various services and other resources that are provided by the computer server by such hacking and other malicious operations, identify such API requests as being invalid, and prevent processing of invalid API requests by the computer server.
Furthermore, the combination of Krishnaiah in view of Morrison does not disclose, but Liu discloses, preparing data for classification by formatting the data as an image and classifying the data using a convolutional neural network (CNN) (Liu: Figure 2 and paragraph 0041).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teaching of Krishnaiah in view of Morrison to include the formatting the data as an image and classifying the image using a CNN as taught by Liu. The motivation would be that Liu teaches that formatting the data as an image and classifying the data using a CNN helps machine learning models classify information in a more accurate manner (Liu: Abstract).
Regarding claims 8 and 23, claims 8 and 23 are directed to a method having similar scope to claims 1 and 22, and are therefore rejected for the same reasons.
Regarding claims 15 and 24; claims 15 and 24 are directed to a computer-readable medium having similar scope to claims 1 and 22, and are therefore rejected for the same reasons.
Claims 5, 12 and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Sanjeevaiah Krishnaiah et al. (Krishnaiah) U.S. Pub. Number 2019/0364028 in view of Morrison U.S. Pub. Number 2019/0036878 and Liu et al U.S. Pub. Number US 2018/0189612 as applied above, and further in view of Wu et al. (Wu) U.S. Pub. Number 2023/0041256.
Regarding claim 5; the combination of Krishnaiah, Morrison and Liu discloses the system of claim 1.
The combination above does not disclose, but Wu discloses, wherein the CNN is a ResNet CNN (Wu: para. [0096] normalized spectrum features are inputted into a neural network model, such as a deep residual network (ResNet) based on a convolutional neural network (CNN), so that the neural network model constructs a model for the normalized spectrum features).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teaching of Krishnaiah, in view of Morrison and Liu to provide the CNN as a ResNet CNN, as taught by Wu. The motivation would be that they are easy to adjust and can improve the accuracy by adding considerable depth.
Regarding claim 12; claim 12 is directed to a method having similar scope as claim 5. Therefore, claim 12 is rejected for the same reasons.
Regarding claim 19; claim 19 is directed to a computer-readable medium having similar scope as claim 5. Therefore, claim 19 is rejected for the same reasons.
Claims 6-7, 13-14 and 20-21 are rejected under 35 U.S.C. 103 as being unpatentable over Sanjeevaiah Krishnaiah et al. (Krishnaiah) U.S. Pub. Number 2019/0364028 in view of Morrison U.S. Pub. Number 2019/0036878 and Liu et al U.S. Pub. Number US 2018/0189612 as applied above, and further in view of Kuperman et al. (Kuperman) U.S. Pub. Number 2018/0278624.
Regarding claim 6; the combination of Krishnaiah in view of Morrison and Liu discloses the system of claim 1.
The combination above does not disclose, but Kuperman discloses, wherein separating the sensor data and the API message comprises removing the sensor data from a header of the API message (Kuperman: para. [0044] authenticator 210 inspects the received API request. For example, the authenticator 210 checks a header of the received API request for any token and checks for an IP address associated with the client from which the API request was received; para. [0045] fig. 3, the authenticator 210 may call the token verifier 217 to verify a token every time a token is presented in association with an API request).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teaching of Krishnaiah, in view of Morrison and Liu to provide removing the sensor data from a header of the API message, as taught by Kuperman. The motivation would be to provide protection to API endpoints and discard API requests that cannot be properly authenticated in order to protect the API from unauthenticated access.
Regarding claim 7; the combination of Krishnaiah in view of Morrison and Liu discloses the system of claim 1.
The combination above does not disclose, but Kuperman discloses, wherein the sensor data in the combined API message is timestamped and encrypted (Kuperman: para. [0048] token verifier 217 verifies tokens presented with API requests…the token verifier 217 may include a private key for decrypting information encrypted by the SDK 225 with a public encryption key… the token verifier 217 may check a timestamp of a token against a current time).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teaching of Krishnaiah in view of Morrison and Liu to provide API messages that are timestamped and encrypted, as taught by Kuperman. The motivation would be to provide protection to API endpoints and discard API requests that cannot be properly authenticated in order to protect the API from unauthenticated access.
Regarding claims 13-14; claims 13-14 are directed to a method having similar scope to claims 6-7, respectively. Therefore, claims 13-14 are rejected for the same reasons.
Regarding claims 20-21; claims 20-21 are directed to a computer-readable medium having similar scope as claims 6-7, respectively. Therefore, claims 20-21 are rejected for the same reasons.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner
should be directed to WILLIAM R KORZUCH whose telephone number is (571) 272-7589. The examiner
can normally be reached Mon.-Fri. 8:00-4:00.
Information regarding the status of published or unpublished applications may be obtained from
Patent Center. Unpublished application information in Patent Center is available to registered users. To
file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit
https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and
https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional
questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like
assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or
571-272-1000.
/WILLIAM R KORZUCH/Supervisory Patent Examiner, Art Unit 2491
Prosecution Insights