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 . In communications filed on 08/05/2026. Claims 1, and 11 are amended. Claims 10, and 20 are cancelled. Claims 1-9, and 11-19 are pending in this examination.
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 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. This examination is in response to US Patent Application No. 18/525,333.
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 has been entered.
Response to Arguments
Applicants’ arguments filed 08/05/2026 have been fully considered but they are not persuasive:
Applicant submits on pages 8-9 of remarks filed on 08/05/2026 regarding claims 1, and 11 that “this is beneficial for automatically discovering which API fields contain user- specific sensitive data without requiring manual configuration or predefined field lists. Additionally, the bin-based distinct-user count combined with the second predetermined number of distinct values per user distinguishes genuinely sensitive fields from false positives that are unique merely due to normal system operation (e.g., timestamps or randomly generated values unique to each API transaction), thereby reducing processing burden by eliminating non-sensitive and false positive fields from further analysis. Furthermore, the verification of the sensitive field against the originating user account prevents further abuse of a predictable field while remaining seamless from the perspective of the end user”.
Examiner respectfully disagrees with applicant argument for claims 1, and 11 filed on 08/05/2026 on pages 8-9 of remarks.
Applicant has not indicated which limitations in the claims are not mapped properly by the references mentioned in this office action, the argument that mentioned above is not included in claims 1, and 11 and these arguments are not part of the claims.
Examiner maintains the rejection and refers applicant to the mapping for more clarification.
Applicant’s amendment to claims 1, and 11 obviates previously raised claims 1-9, and 11-19 U.S.C .101 Alice decision rejection.
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 of this title, 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.
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:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 1-9, and 11-19 are rejected under 35 U.S.C. 103 as being unpatentable over US Palanki (2023/0376811) , and in view of Mahoney ( US2023/0396438), and further in view of Ionescu ( US2017/0109541).
Regarding claims 1, and 11, Palanki discloses A method performed by a processor, the method comprising: in a learning phase: collecting a subset of application programming interface (API) transactions between a plurality of users and a host system
[Abstract, Disclosed are various approaches for using Markov chains and hidden Markov Models to enhance API access controls for secure data. Various embodiments disclosed in this application introduce an access control application between the APIs and a data store that uses Markov chains or hidden Markov models to validate, check, or verify that the data request meets expected security guidelines. These embodiments can enhance security for all requests for data. Additionally, these embodiments can serve as an additional, automated security defense when a developer misconfigures or fails to include the appropriate validation logic within an API.], and
[¶12, Disclosed are various approaches for using Markov chains and hidden Markov Models to enhance API access controls for secure data. Software systems can use a set of Application Programming Interfaces (APIs) as an organized way to access stored data. In many implementations, developers of each API can be responsible for determining whether a client's request to access the stored data is valid. In development teams having many developers writing and managing these APIs, the implementation of security measures can often be prone to error, misconfigured, or outdated from expected security guidelines. For instance, an API may have broken user authentication, broken object level authorization, broken function level authorization, excessive data exposure, or, generally, various security misconfigurations. There are various industries, like healthcare and financial services, where these security concerns are critical problems due to the sensitive nature of the data stored], and
[¶17, A client device 106 can represent one or more devices in connection with the computing environment 109 over the network 103. For example, the client device 106 can be a mobile phone, tablet, laptop, desktop, or other devices used by an end-user (e.g., a customer, a patient, a card holder, an account holder, etc.)( equated to plurality of users)], and [ ¶20, The client device 106 can be configured to execute various applications, such as a client application 112 or other applications. The client application 112 can be executed in a client device 106 to access network content served up by the computing environment 109 or other servers, thereby rendering a user interface on the display 115. To this end, the client application 112 can include a browser, a dedicated application, or other executable, and the user interface can include a network page, an application screen, or other user mechanism for obtaining user input. The client device 106 can be configured to execute applications beyond the client application 112 such as email applications, social networking applications, word processors, spreadsheets, or other applications], and [¶25, The data 121 can represent various types of data that a business or user wants to keep secure. Examples of data 121 can include personally identifying information such as an individual's name, age, birthday, height, weight, social security number, identification number, driver's license number, or other identifying information about the end user. The data 121 can also include password-related information the end user may want to keep private from others, such as password hints and password recovery answers], and [¶27, In at least some embodiments, the data 121 can include reports, aggregated data, and/or summaries of the previously mentioned data. For instance, the data 121 can include a credit report based at least in part on the user's credit transaction information. In another example, the data 121 can include an aggregated list of unpaid balances, bounced payments, or outstanding payments. In at least another embodiment, the data 121 can include a summary of a patient's medication. Data 121 can include other data that a user may want to keep secured]; and
analyzing fields in the subset of API transactions by, extracting data values from each field, building a log history of values for each field, wherein each value is placed in a bin corresponding to users associated with the value, and determining a number of distinct users per value based on the bin and a number of distinct values of the field held by each user
[¶¶24-25, Various data is stored in a data store 118 that is accessible to the computing environment 203. The data store 118 can be representative of a plurality of data stores 118, which can include relational databases or non-relational databases such as object-oriented databases, hierarchical databases, hash tables or similar key-value data stores, as well as other data storage applications or data structures. Moreover, combinations of these databases, data storage applications, and/or data structures may be used together to provide a single, logical, data store. The data stored in the data store 118 is associated with the operation of the various applications or functional entities described below. This data can include data 121… The data 121 can represent various types of data that a business or user wants to keep secure. Examples of data 121 can include personally identifying information such as an individual's name, age, birthday, height, weight, social security number, identification number, driver's license number, or other identifying information about the end user. The data 121 can also include password-related information the end user may want to keep private from others, such as password hints and password recovery answers.
[¶27, In at least some embodiments, the data 121 can include reports, aggregated data, and/or summaries of the previously mentioned data. For instance, the data 121 can include a credit report based at least in part on the user's credit transaction information. In another example, the data 121 can include an aggregated list of unpaid balances, bounced payments, or outstanding payments. In at least another embodiment, the data 121 can include a summary of a patient's medication. Data 121 can include other data that a user may want to keep secured]
[¶¶32-33, The API gateway 130 can be executed to receive, intercept, validate, and/or route communications between the client application 112 on the client device 106 with one or more of the APIs 133 on the computing environment 109. The API gateway 130 can receive a request from client application 112 over the network 100. In at least one embodiment, the API gateway 130 can receive a request that is intended to be received by the API gateway 130. In at least another embodiment, the API gateway 130 can intercept a request being sent to an API 133. In response to receiving the request, the API gateway 130 can introspect various properties of the request, including one or more IP addresses, status codes, tokens, or request header information. The API gateway 130 can determine which API 133 can handle the request based at least in part on the previously mentioned properties of the request. Additionally, the API gateway 130 can perform a simple validation on any of the data in the request. If the information is invalid, the API gateway 130 can send a response indicating the request was invalid to the client application 112. Alternatively, the API gateway 130 can route or otherwise send an invalid request to an API 133 for special handling or additional processing. If a request is determined to be valid or if no validation occurs, the API gateway 130 can route or otherwise send the request to one or more APIs 133 for additional processing…] , and [¶¶12, 20].
Examiner Note: As indicated in Palanki application , the datastore( equated to log history) holds various information for each user separately ( equated to bin) and it would have been obvious to one of ordinary skill in the art to create different bins or columns and rows in a datastore for plurality of uses.
identifying the fields as sensitive fields when information in the fields is common to less than or equal to a first predetermined number of the plurality of users and each of the users holds less than or equal to a second predetermined number of distinct values of the field
[¶12, Disclosed are various approaches for using Markov chains and hidden Markov Models to enhance API access controls for secure data. Software systems can use a set of Application Programming Interfaces (APIs) as an organized way to access stored data…., an API may have broken user authentication, broken object level authorization, broken function level authorization, excessive data exposure, or, generally, various security misconfigurations. There are various industries, like healthcare and financial services, where these security concerns are critical problems due to the sensitive nature of the data stored], and
[¶25, The data 121 can represent various types of data that a business or user wants to keep secure. Examples of data 121 can include personally identifying information such as an individual's name, age, birthday, height, weight, social security number, identification number, driver's license number, or other identifying information about the end user. The data 121 can also include password-related information the end user may want to keep private from others, such as password hints and password recovery answers], and [¶27, In at least some embodiments, the data 121 can include reports, aggregated data, and/or summaries of the previously mentioned data. For instance, the data 121 can include a credit report based at least in part on the user's credit transaction information. In another example, the data 121 can include an aggregated list of unpaid balances, bounced payments, or outstanding payments. In at least another embodiment, the data 121 can include a summary of a patient's medication. Data 121 can include other data that a user may want to keep secured] ; and
Examiner Note: As indicated in Palanki application , the datastore( equated to log history) holds various information for each user separately ( equated to bin) such as social security number and each user in the datastore will have this information in their own bin, and when it is determined that number of SSN is common to each of the users and is equal to the predetermined number ( which is predetermined, could be any number), then identify that the SSN is a sensitive field, and if the second predetermined number is equal to one , it would have been obvious to one of ordinary skill in the art that each user has only one representation of SSN in the datastore and in their own bin, in other words , no user will have two or more SSN in their own bin.
and in an implementation phase: analyzing the sensitive fields for vulnerabilities including determining when predictable patterns are present in the values of the sensitive fields
[¶12, Disclosed are various approaches for using Markov chains and hidden Markov Models to enhance API access controls for secure data. Software systems can use a set of Application Programming Interfaces (APIs) as an organized way to access stored data. In many implementations, developers of each API can be responsible for determining whether a client's request to access the stored data is valid. In development teams having many developers writing and managing these APIs, the implementation of security measures can often be prone to error, misconfigured, or outdated from expected security guidelines. For instance, an API may have broken user authentication, broken object level authorization, broken function level authorization, excessive data exposure, or, generally, various security misconfigurations. There are various industries, like healthcare and financial services, where these security concerns are critical problems due to the sensitive nature of the data stored
and performing corrective measures to protect the usage of the sensitive fields that are determined to be vulnerable, including verifying that the information in the sensitive fields is associated with a user account involved in subsequent API transactions, the verifying including modifying a procedure of the subsequent API transactions to perform a back-end verification that the information is associated with the user account from which the subsequent API transaction originates
[ Abstract, Disclosed are various approaches for using Markov chains and hidden Markov Models to enhance API access controls for secure data. Various embodiments disclosed in this application introduce an access control application between the APIs and a data store that uses Markov chains or hidden Markov models to validate, check, or verify that the data request meets expected security guidelines. These embodiments can enhance security for all requests for data. Additionally, these embodiments can serve as an additional, automated security defense when a developer misconfigures or fails to include the appropriate validation logic within an API], and [¶¶12-13, Disclosed are various approaches for using Markov chains and hidden Markov Models to enhance API access controls for secure data. Software systems can use a set of Application Programming Interfaces (APIs) as an organized way to access stored data. In many implementations, developers of each API can be responsible for determining whether a client's request to access the stored data is valid. In development teams having many developers writing and managing these APIs, the implementation of security measures can often be prone to error, misconfigured, or outdated from expected security guidelines. For instance, an API may have broken user authentication, broken object level authorization, broken function level authorization, excessive data exposure, or, generally, various security misconfigurations. There are various industries, like healthcare and financial services, where these security concerns are critical problems due to the sensitive nature of the data stored. To solve these problems, various embodiments disclosed in this application introduce an access control application between the APIs and a data store that uses Markov chains or hidden Markov models to validate, check, or verify that the data request meets expected security guidelines. These embodiments can enhance security for all requests for data. Additionally, these embodiments can serve as an additional, automated security defense when a developer misconfigures or fails to include the appropriate validation logic within an API. ], and [¶25, The data 121 can represent various types of data that a business or user wants to keep secure. Examples of data 121 can include personally identifying information such as an individual's name, age, birthday, height, weight, social security number, identification number, driver's license number, or other identifying information about the end user. The data 121 can also include password-related information the end user may want to keep private from others, such as password hints and password recovery answers].
Examiner Note: As indicated in Palaki application, the implementation of security measures can often be prone to error, misconfigured, or outdated from expected security guidelines. For instance, an API may have broken user authentication, broken object level authorization, broken function level authorization, excessive data exposure, or, generally, various security misconfigurations, by implementing, an access control application between the APIs and a data store that uses Markov chains or hidden Markov models enables to validate, check, or verify that the data request meets expected security guidelines. It would have been obvious to one of ordinary skill in the art to indicate that before any API transaction to verify if there is any sensitive filed in the subsequent API tansactions.
While Palanki discloses each of the API transactions including a data structure having a plurality of fields as:
[¶¶24-25, Various data is stored in a data store 118 that is accessible to the computing environment 203. The data store 118 can be representative of a plurality of data stores 118, which can include relational databases or non-relational databases such as object-oriented databases, hierarchical databases, hash tables or similar key-value data stores, as well as other data storage applications or data structures. Moreover, combinations of these databases, data storage applications, and/or data structures may be used together to provide a single, logical, data store. The data stored in the data store 118 is associated with the operation of the various applications or functional entities described below. This data can include data 121… The data 121 can represent various types of data that a business or user wants to keep secure. Examples of data 121 can include personally identifying information such as an individual's name, age, birthday, height, weight, social security number, identification number, driver's license number, or other identifying information about the end user. The data 121 can also include password-related information the end user may want to keep private from others, such as password hints and password recovery answers].
However, Palanki does not explicitly disclose, and Mahoney discloses each of the API transactions including a data structure having a plurality of fields as:
[¶33, In one or more embodiments, an API call may include one or more fields or portions in which information is to be provided. The information to be provided in any number of such fields of a given API call may be deemed sensitive. As an example, the service provider may deem certain fields as sensitive data, such as an account identifier, personally identifiable information (e.g., name, date of birth, email address, phone number, Internet Protocol (IP address), passport number, account number(s) all or any portion of a social security number, etc.), information subject to the Payment Card Industry Data Security Standard (PCI DSS), protected health information (PHI), etc. In one or more embodiments, when an API call includes one or more fields or portions deemed sensitive, such fields or portions may be required to be encrypted to make the API call, so that the information if the one or more fields or portions of the API call is not exposed. Therefore, one or more fields or portions of an API call may be designated as requiring encryption. Such a designation may be made in any manner identifiable by the user application 104. As an example, a given field or portion of an API call may be associated with a character string (e.g., “cipher”) that designates the field or portion as having been deemed sensitive and requiring encryption. In such an example, the account identifier field may be so designated with “cipher. accountId, which indicates to the user application that the account identifier field should be encrypted].
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 Palanki by incorporating “an API call with one or more field”, as taught by Mahoney. One could have been motivated in order to identify the information to be provided in any number of such fields of a given API call may be deemed sensitive. As an example, the service provider may deem certain fields as sensitive data, such as an account identifier, personally identifiable information (e.g., name, date of birth, email address, phone number, Internet Protocol (IP address), passport number, account number(s) all or any portion of a social security number, etc.), information subject to the Payment Card Industry Data Security Standard (PCI DSS), protected health information (PHI) [ Mahoney, ¶33].
While Palanki discloses grouping the API transactions per user as:
[ ¶20, The client device 106 can be configured to execute various applications, such as a client application 112 or other applications. The client application 112 can be executed in a client device 106 to access network content served up by the computing environment 109 or other servers, thereby rendering a user interface on the display 115. To this end, the client application 112 can include a browser, a dedicated application, or other executable, and the user interface can include a network page, an application screen, or other user mechanism for obtaining user input. The client device 106 can be configured to execute applications beyond the client application 112 such as email applications, social networking applications, word processors, spreadsheets, or other applications]
[¶25, The data 121 can represent various types of data that a business or user wants to keep secure. Examples of data 121 can include personally identifying information such as an individual's name, age, birthday, height, weight, social security number, identification number, driver's license number, or other identifying information about the end user. The data 121 can also include password-related information the end user may want to keep private from others, such as password hints and password recovery answers.
[¶¶32-33, The API gateway 130 can be executed to receive, intercept, validate, and/or route communications between the client application 112 on the client device 106 with one or more of the APIs 133 on the computing environment 109. The API gateway 130 can receive a request from client application 112 over the network 100. In at least one embodiment, the API gateway 130 can receive a request that is intended to be received by the API gateway 130. In at least another embodiment, the API gateway 130 can intercept a request being sent to an API 133. In response to receiving the request, the API gateway 130 can introspect various properties of the request, including one or more IP addresses, status codes, tokens, or request header information. The API gateway 130 can determine which API 133 can handle the request based at least in part on the previously mentioned properties of the request. Additionally, the API gateway 130 can perform a simple validation on any of the data in the request. If the information is invalid, the API gateway 130 can send a response indicating the request was invalid to the client application 112. Alternatively, the API gateway 130 can route or otherwise send an invalid request to an API 133 for special handling or additional processing. If a request is determined to be valid or if no validation occurs, the API gateway 130 can route or otherwise send the request to one or more APIs 133 for additional processing…].
Furthermore, Mahoney discloses grouping the API transactions per user as: [ 0033] In one or more embodiments, an API call may include one or more fields or portions in which information is to be provided. The information to be provided in any number of such fields of a given API call may be deemed sensitive. As an example, the service provider may deem certain fields as sensitive data, such as an account identifier, personally identifiable information (e.g., name, date of birth, email address, phone number, Internet Protocol (IP address), passport number, account number(s) all or any portion of a social security number, etc.), information subject to the Payment Card Industry Data Security Standard (PCI DSS), protected health information (PHI), etc. In one or more embodiments, when an API call includes one or more fields or portions deemed sensitive, such fields or portions may be required to be encrypted to make the API call, so that the information if the one or more fields or portions of the API call is not exposed. Therefore, one or more fields or portions of an API call may be designated as requiring encryption. Such a designation may be made in any manner identifiable by the user application 104. As an example, a given field or portion of an API call may be associated with a character string (e.g., “cipher”) that designates the field or portion as having been deemed sensitive and requiring encryption. In such an example, the account identifier field may be so designated with “cipher. accountId, which indicates to the user application that the account identifier field should be encrypted.
However, Palanki, and Mahoney do not explicitly disclose, and Ionescu discloses grouping the API transactions per user as: [Abstract, A method of classifying privacy relevance of an application programming interface (API) comprises analyzing a set of input applications to identify a plurality of custom APIs and generating a respective taint specification for each identified custom API. The method further comprises generating taint flows based on each taint specification and matching features and associated feature values from the taint flows to a set of feature templates. The method also comprises correlating the matched features and associated feature values with respective privacy relevance of the plurality of custom APIs to identify a set of privacy relevant features. The method further comprises detecting a candidate API, extracting features from the candidate API and comparing the extracted features to the set of privacy relevant features. Based on the comparison, a label is assigned to the candidate API indicating privacy relevance of the candidate AP
[¶21, In operation, the computer system 100 is configured to automatically detect and characterize privacy-relevant uses of custom privacy application programming interfaces (APIs). As used herein, the terms “custom privacy API” and “custom API” are used interchangeably and refer to an API which may or may not convey sensitive or private information depending on the implementation of the API. In other words, a custom API has the potential to convey sensitive or private information, but, depending on the implementation, may not be a source or a sink of sensitive information. One such type of a custom API is an editable text box. Data input into the text field can be non-sensitive data or sensitive data depending on the custom use of the API. For example, the text box could be used to collect sensitive data such as social security numbers or credit card numbers. However, it is to be understood that custom APIs are not limited to text boxes. Additionally, as used herein, the terms “privacy”, “sensitive”, and “security” can be used interchangeably in reference to data which is not to be shared publicly or exposed to public discovery, such as via custom APIs.
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 Palanki, and Mahoney by incorporating “custom privacy application programming interfaces (APIs)”, as taught by Ionescu. One could have been motivated in order to use the custom API to convey sensitive or private information [ Ionescu, ¶21].
Regarding claims 2, and 12, Palanki discloses: identifying the fields as non-sensitive fields when information in the fields is common to more than the first predetermined number of the plurality of users; and ignoring the non-sensitive fields in subsequent API transactions [¶¶25-26, The data 121 can represent various types of data that a business or user wants to keep secure. Examples of data 121 can include personally identifying information such as an individual's name, age, birthday, height, weight, social security number, identification number, driver's license number, or other identifying information about the end user. The data 121 can also include password-related information the end user may want to keep private from others, such as password hints and password recovery answers. In some embodiments, the data 121 can include cardholder data that is secured under Payment Card Industry Data Security Standard (PCI-DSS) compliance standards, such as a cardholder's name, an account number, and information about a specific card, such as a card identification number, an expiration date, and a security code. Further, the data 121 can include transaction data, such as a date of a transaction, the amount spent in the transaction, the paying entity, the entity that was paid, a brief description of the transaction, and/or any additional information related to the transaction. As another example, the data 121 can include secure communications between two or more entities. For instance, the data 121 can include secure messages between a payment card (credit, debit, charge, etc.) issuer and an end-user. In at least another embodiment, the data 121 can include patient data that is secured under Health Insurance Portability and Accountability Act (HIPAA) compliance standards, such as patient health records, patient identifying information, or any other information secured under HIPAA compliance standards].
Regarding claims 3, and 13, Palanki discloses: identifying the fields as false positive fields when information in the fields is distinct to over a predetermined number of API transactions for a user of the plurality of users; and ignoring the false positive fields in subsequent API transactions [¶12, Disclosed are various approaches for using Markov chains and hidden Markov Models to enhance API access controls for secure data. Software systems can use a set of Application Programming Interfaces (APIs) as an organized way to access stored data. In many implementations, developers of each API can be responsible for determining whether a client's request to access the stored data is valid. In development teams having many developers writing and managing these APIs, the implementation of security measures can often be prone to error, misconfigured, or outdated from expected security guidelines. For instance, an API may have broken user authentication, broken object level authorization, broken function level authorization, excessive data exposure, or, generally, various security misconfigurations. There are various industries, like healthcare and financial services, where these security concerns are critical problems due to the sensitive nature of the data stored].
Regarding claims 4, and 14, Palanki discloses, analyzing the fields in the subset of API transactions comparing the grouped API transactions across the plurality of users [¶12, Disclosed are various approaches for using Markov chains and hidden Markov Models to enhance API access controls for secure data. Software systems can use a set of Application Programming Interfaces (APIs) as an organized way to access stored data. In many implementations, developers of each API can be responsible for determining whether a client's request to access the stored data is valid. In development teams having many developers writing and managing these APIs, the implementation of security measures can often be prone to error, misconfigured, or outdated from expected security guidelines. For instance, an API may have broken user authentication, broken object level authorization, broken function level authorization, excessive data exposure, or, generally, various security misconfigurations. There are various industries, like healthcare and financial services, where these security concerns are critical problems due to the sensitive nature of the data stored].
Regarding claims 5, and 15, Palanki discloses further comprising: analyzing the API transactions including API requests from the plurality of users to the host system for information and API responses from the host system to the plurality of users with the requested information [¶33, The APIs 133 can be executed to perform a various number of tasks. Each API 133 can be configured to receive a request from the client application 112 over the network 100 or receive a request from the API gateway 130. In at least one embodiment, an API 133 can receive a request directly from client application 112 over the network 100. In at least another embodiment, an API 133 can receive a request being sent from the API gateway 130. In response to receiving the request, an API 133 can introspect various properties of the request, including one or more IP addresses, status codes, tokens, or request header information. The API 133 can validate any of the data in the request. If the information is invalid, the API 133 can send a response indicating the request was invalid to the client application 112. During its execution, the API 133 may want to access data 121 from the data store 118 to process or transmit in a response to the client application 112. To access the data 121, the API 133 can send a request to access a portion of the data 121 on the data store 118. To do so, the API 133 can directly send a request to the data store 118, which can be intercepted by the access control application 136. Alternatively, the API 133 can send a request directly to the access control application 136, which can provide access to the data store 118. The API 133 can receive a response from the access control application 136 or from the data store 118. The response from the data store 118 or the access control application 136 can contain data 121, a status code, or various other information. The API 133 can forward the response or transmit, over the network 103, a new response to the client application 112 on the client device 106. The API 133 can do other various tasks that are not listed here, including processing data, authorizing transactions, directing data to be stored in the data store 118, or other various actions. This disclosure is not intended to limit the scope of the type of actions that the API 133 can be executed to perform], and [Abstract, ¶¶40, 42, 63].
Regarding claims 6, and 16, Palanki discloses, wherein the sensitive fields include at least one of private account information of the plurality of users or private personal information of the plurality of users [¶12, Disclosed are various approaches for using Markov chains and hidden Markov Models to enhance API access controls for secure data. Software systems can use a set of Application Programming Interfaces (APIs) as an organized way to access stored data. In many implementations, developers of each API can be responsible for determining whether a client's request to access the stored data is valid. In development teams having many developers writing and managing these APIs, the implementation of security measures can often be prone to error, misconfigured, or outdated from expected security guidelines. For instance, an API may have broken user authentication, broken object level authorization, broken function level authorization, excessive data exposure, or, generally, various security misconfigurations. There are various industries, like healthcare and financial services, where these security concerns are critical problems due to the sensitive nature of the data stored], and [¶¶25-26, The data 121 can represent various types of data that a business or user wants to keep secure. Examples of data 121 can include personally identifying information such as an individual's name, age, birthday, height, weight, social security number, identification number, driver's license number, or other identifying information about the end user. The data 121 can also include password-related information the end user may want to keep private from others, such as password hints and password recovery answers. In some embodiments, the data 121 can include cardholder data that is secured under Payment Card Industry Data Security Standard (PCI-DSS) compliance standards, such as a cardholder's name, an account number, and information about a specific card, such as a card identification number, an expiration date, and a security code].
Regarding claims 7, and 17, Palanki discloses, wherein the first predetermined number is set to 1 or to a value representing a number of users that share a common account on the host system [¶19, In another embodiment, the client device 106 can represent one or more of a plurality of client devices that can be coupled to the network 103. The client device 106 can include a processor-based system such as a computer system].
Regarding claims 8, and 18, Palanki discloses collecting the subset of API transactions and analyzing the fields in the subset of API transactions either periodically or upon request by the host system [¶12, Disclosed are various approaches for using Markov chains and hidden Markov Models to enhance API access controls for secure data. Software systems can use a set of Application Programming Interfaces (APIs) as an organized way to access stored data. In many implementations, developers of each API can be responsible for determining whether a client's request to access the stored data is valid. In development teams having many developers writing and managing these APIs, the implementation of security measures can often be prone to error, misconfigured, or outdated from expected security guidelines. For instance, an API may have broken user authentication, broken object level authorization, broken function level authorization, excessive data exposure, or, generally, various security misconfigurations. There are various industries, like healthcare and financial services, where these security concerns are critical problems due to the sensitive nature of the data stored], and [¶82, At block 809, the access control application 136 can determine a first access control state 142 from the plurality of access control states 142. In at least one embodiment, the access control application 136 can make this determination based at least in part on at least one or more attributes of the token. For example, the access control application 136 can introspect the token to determine that it has an expiration datetime set to a date/time that has already passed. In this situation, the access control application 136 can determine that an access control state 142 is in an “unauthenticated” state or an “expired” state].
Regarding claims 9, and 19, Palanki discloses prior to the performing of the corrective measures, determining if the sensitive fields are being abused, and performing the corrective measures to protect the usage of the sensitive fields that are determined to be abused [¶12, Disclosed are various approaches for using Markov chains and hidden Markov Models to enhance API access controls for secure data. Software systems can use a set of Application Programming Interfaces (APIs) as an organized way to access stored data. In many implementations, developers of each API can be responsible for determining whether a client's request to access the stored data is valid. In development teams having many developers writing and managing these APIs, the implementation of security measures can often be prone to error, misconfigured, or outdated from expected security guidelines. For instance, an API may have broken user authentication, broken object level authorization, broken function level authorization, excessive data exposure, or, generally, various security misconfigurations. There are various industries, like healthcare and financial services, where these security concerns are critical problems due to the sensitive nature of the data stored].
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
See submitted 892 for more relevant references.
ZHOU(CN 113515771 A) This application aims to solve at least one of the technical problems existing in the prior art. To this end, this application proposes a data sensitivity determination method, which can conduct a comprehensive analysis of sensitive information, improve the accuracy of identifying sensitive information, and effectively avoid the problem of information leakage.
Wilshinky(US20210173854) A method includes receiving, by a logic layer processor, over a communication network, from a plurality of electronic resources, initial user personal identifiable information (PII) of a user of a plurality of users. The user PII includes a plurality of data elements. The plurality of data elements of the initial PII of the user are classified to populate a profile map data structure having a standardized predefined data schema of a plurality of vector elements so as to form a user-specific profile map data structure of the user. Additional user personal identifiable information (PII) of the user is iteratively received from the plurality of electronic resources. The additional user PII of the user is iteratively classified to update the user-specific profile map data structure of the user. A plurality of user-specific data management software functions is enabled based on the user-specific profile map data structure.
Staley (US10,650,155) (7) A client device 102 is a computer system used by users to communicate with the content management system 104 via the network 106. A client device 102 may be, for example, a personal computer, a mobile phone, a tablet, or a personal digital assistant (PDA). Through a client device 102 users of content management system 104 can provide content items to content management system 104 for storage. A content item may include one or more of the following: digital data, audio, video, text, images, and documents. (8) Further, each client device 102 includes a client application 108 through which a user of the device can access a user interface to communicate with the content management system 104. The client application 108 can be, for example, a web browser or an application (e.g., mobile or desktop application) specifically designed to communicate with the content management system 104. (13, 22, 24, 32, 37, 38, 41)
Dilip (US2008/0086403) [ [0043] Financial management system 118 performs various account analysis functions to determine whether a user's financial accounts (e.g., both asset accounts and debt accounts) are optimized. Additionally, financial management system 118 is capable of initiating the automatic transfer of funds between accounts at one or more financial institutions. These analysis and fund transfer functions are discussed in greater detail below. Wireless device 112 and client computer 114 allow a user to access information via the network 108. For example, the user can access account information from one of the financial institution servers 102, 104, or 106, access current interest rate data from market information service server 110, or send a request for an analysis of the user's financial accounts to financial management system 118. Financial information provider 116 acts as an intermediary between client computer 114 and other devices coupled to network 108. For example, client computer 114 generates a request for data or account analysis and communicates the request to the financial information provider 116. The financial information provider 116 then retrieves the requested data or initiates the requested account analysis on behalf of the user of client computer 114], and [ see FIG. 13 and corresponding text for more details]., and [¶¶36,41,63, 119, 127].
Any inquiry concerning this communication or earlier communications from the examiner should be directed to SHAHRIAR ZARRINEH whose telephone number is (571)272-1207. The examiner can normally be reached Monday-Friday, 8:30am-5:30pm.
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.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Jorge Ortiz-Criado can be reached at 571-272-7624. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
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.
/SHAHRIAR ZARRINEH/Primary Examiner, Art Unit 2496
Prosecution Insights