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 .
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 5, 12 and 19 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Claims 5, 12 and 19 recite the limitation "the CNN". There is insufficient antecedent basis for this limitation in the claims.
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 determine if a human is operating the API client (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; para. [0030] information about user 102 (e.g., height of user 102, facial recognition and/or imaging, biometric readings, clothing of user 102, etc.), and/or real-world/environmental conditions for an environment that communication device 110 is used within (e.g., location, temperature, humidity, time of day, light levels, noise, etc.). Data collection module 112 may store the determined user data to database 116 for use with authentication profiles; para. [0050] using user data 1110, which may be used to determine current user authentication 1102… based on user data 1110, other authentication paths 1112 may be selected based on the capabilities of communication device 110 and/or available data in user data);
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, 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.
Response to Arguments
Applicant’s arguments with respect to the claims have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to 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