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 Arguments
Rejections under 35 U.S.C. §103
Applicant's arguments filed 7/20/26 have been fully considered but they are not persuasive.
Schwarzbauer 's paragraph [0193] does not describe a mapping between source code identifiers and data categories as required by the claims. Rather, Schwarzbauer describes an "instrumentation/vulnerability mapping entry" that maps an instrumentation identifier to vulnerable libraries. Specifically, Schwarzbauer states that "[a]n instrumentation/ vulnerability mapping entry 146 may contain but is not limited to an instrumentation identifier 721, which identifies a vulnerable API instrumentation config 200 and a vulnerable library identifiers list 722, containing identifies [sic] for all libraries containing the vulnerable APIs that match the vulnerable API instrumentation config 200 identified by the instrumentation identifier 721." Schwarzbauer, paragraph [0193]. The output side of Schwarzbauer's mapping is thus a list of vulnerable libraries (identified by vendor name, product name, and version) not a data category indicating a data type or data processing purpose type as recited in the claims. This is a fundamental mismatch: the claims require that the detector specification's mappings produce data categories ( e.g., location data, cookie data, analytics, digital advertisement targeting), whereas Schwarzbauer 's mapping produces library identifiers and vulnerability report identifiers. No amount of modification to Schwarzbauer's mapping structure would yield the claimed data categories without changing the very nature and purpose of Schwarzbauer 's system.
Barday discloses a recognized association between a source code identifier (e.g. col. 70, lines 3-5 “identify Gusto”) and a vulnerability in the form of data categories associated with data processing activity components (col. 70, lines 3-5 “recognize that Gusto stores expense information”) but does not explicitly disclose a mechanism for making this association. Schwarzbauer’s “list of library identifiers” identifies source code (e.g. par. [0193] “a vulnerable library identifiers list 722”) and maps that source code to a vulnerability (e.g. par. [0193] “identifies a vulnerable API instrumentation config 200”). Accordingly, Schwarzbauer teaches a detector specification comprising mappings between source code identifiers and vulnerabilities.
It would have been obvious to use Schwarzbauer’s detector specification to map the associations disclosed in Barday’s as a “fast and efficient” (Schwarzbauer par. [0193]) means of performing the functionality disclosed by Barday.
Additionally, it is noted that the rejection in question does not require that Schwarzbauer’s “very nature and purpose” be preserved (see e.g. MPEP “If a proposed modification would render the prior art invention being modified unsatisfactory for its intended purpose” (see e.g. MPEP § (V-VI) “If a proposed modification would render the prior art invention being modified unsatisfactory”).
The structural content of Schwarzbauer 's mapping confirms this mismatch. The vulnerable library identifiers list contains records identifying "a vulnerability report identifier 724, which identifies a specific vulnerability report 148, and a library identifier 725, which identifies a specific library that is affected by the vulnerability identified by the vulnerability report identifier 724, e.g., by a vendor name, a product name, and a version." Schwarzbauer, paragraph [0194]. Vulnerability report identifiers, vendor names, product names, and version numbers are not "data categories" indicating "one or more data types or one or more data processing purpose types" per se (as recited by claims 1, 11, and 16).
Applicant is correct that a “library identifier 725” does not identify “data categories” or “data types”, however they do identify source code (e.g. libraries) as claimed.
Schwarzbauer's stated purpose further confirms the mismatch. Schwarzbauer's mapping exists to identify security vulnerabilities by associating placed sensors with vulnerability reports so that, upon receipt of API call data, the system can locate the corresponding vulnerable library. As Schwarzbauer explains, "[m]aintaining a mapping between placed vulnerable API sensors and vulnerability reports/vulnerable APIs that caused the placement of those sensors, together with vulnerable API sensor executions providing report data that contains identification data (instrumentation identifier) of the sensor creating the report data greatly eases the identification of corresponding vulnerabilities/affected libraries for received vulnerable API call report data." Schwarzbauer, paragraph [0229]. By Schwarzbauer 'sown description, the mapping is a vulnerability-to-library lookup not a source-code-identifier-to-data-category lookup.
As noted above, Barday discloses associating/mapping a source code identifier (e.g. col. 70, lines 3-5 “identify Gusto”) with/to a vulnerability (col. 70, lines 3-5 “recognize that Gusto stores expense information”). Schwarzbauer teaches using a detector specification, e.g. a list, (see e.g. specification par. [0069] “detector specification defines a list”) as a known means of performing Barday’s mapping.
Applicant further submits that neither Woulfe nor Barday cures the deficiencies of Schwarzbauer. … While Barday discloses privacy-related analysis of computer code, Barday does not disclose a "detector specification comprising one or more mappings between one or more source code identifiers and one or more data categories." See Barday, col. 52, lines 19-25, 57-62. Accordingly, even if the references were combined, the resulting combination would still lack the claimed detector specification.
As discussed above, Barday discloses the mapping between “source code identifiers” and “data categories”. Accordingly, the deficiency to be cured is the use of a “detector specification”. Schwarzbauer teaches the claimed “detector specification” and thus cures Barday’s deficiency.
The Office Action's articulated motivation, namely "fast and efficient lookup," does not bridge this gap. While Schwarzbauer indeed states that its mapping enables fast lookup of corresponding vulnerabilities, that benefit is tied to Schwarzbauer 's vulnerability-detection paradigm and has no bearing on Barday 's privacy assessment system. See Schwarzbauer, paragraph [0229] ( describing fast lookup "for received vulnerable API call report data"). The Office Action has not explained why a person of ordinary skill, starting from Barday 's privacy assessment context, would have been motivated to import a security-vulnerability mapping structure; namely, a structure that maps instrumentation identifiers to vulnerable libraries-to perform the entirely different task of mapping source code identifiers to privacy data categories. The asserted benefit of "fast and efficient lookup" is generic and does not supply a rational underpinning for combining Schwarzbauer 's specific structure, directed to vulnerability identification, with Barday 's privacy-attribute analysis. See In re Kahn, 44 l F .3d at 988 (requiring "articulated reasoning with some rational underpinning").
Barday’s “privacy assessment system” is fundamentally a vulnerability analysis (see e.g. Barday col. 2, lines 50-53 “breaches have their roots in vulnerabilities”, ). Accordingly, Barday and Schwarzbauer are analogously directed to analyzing software for vulnerabilities. More specifically, a person of skill in the art would have understood Barday to map identified software to specific data privacy vulnerabilities () but would not find an explicit disclosure of a structure to do so. Schwarzbauer discloses that implementing a “detector specification” was within the ordinary level of skill in the art of vulnerability analysis and would have provided a “fast and efficient” method of providing the desired functionality (e.g. Barday col. 70, lines “recognize that Gusto stores expense information”).
Additionally, even assuming arguendo that a person of ordinary skill would have been motivated to combine the references, the proposed combination would still fail to arrive at the claimed invention. The claims require a "detector specification comprising one or more mappings between one or more source code identifiers and one or more data categories," where the detector specification is used to analyze application code and determine data categories for data processing activity components. Merely transplanting Schwarzbauer 's instrumentation/vulnerability mapping into Barday's system would not produce the claimed detector specification, because (1) Schwarzbauer 's instrumentation identifier (a computed hash) is not a "source code identifier"; (2) Schwarzbauer 's mapping output (vulnerable library identifiers) is not a "data category" indicating data types or data processing purpose types; and (3) Schwarzbauer 's mapping does not function as a specification used to scan application code, but rather as a runtime lookup table used to correlate sensor data with vulnerability reports. The Office Action has not explained what modifications would be necessary to transform Schwarzbauer 's vulnerability mapping into the claimed detector specification, nor why such modifications would have been obvious.
Replacing the data in Schwarzbauer’s specification detector (par. [0193] “”vulnerable library identifiers”, “instrumentation identifier”) with Barday’s data (e.g. “Gusto”, “expense information”) would result in a “detector specification” mapping between source code identifiers and “data categories” as claimed. Such a modification would have required only an ordinary level of creativity (see e.g. MPEP 2141.03).
Claim Rejections - 35 USC § 103
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 (i.e., changing from AIA to pre-AIA ) 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.
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.
Claim(s) 1-8, and 11-20 is/are rejected under 35 U.S.C. 103 as being unpatentable over US 11,025,675 to Barday et al. (Barday) in view of US 2022/0156383 to Schwarzbauer et al. (Schwarzbauer).
Claims 1, 11 and 16: Barday discloses a computer-implemented method comprising:
receiving, in response to an application code scan, a set of data processing activity components identified within an application code by analyzing the application code and determining mappings between one or more source code identifiers and one or more data categories associated with the set of data processing activity components (col. 70, lines 3-5 “the system may identify Gusto as a primary asset and recognize the Gusto stores expense information “, col. 80, lines 30-33 “searching for particular data fields comprising one or more pieces of information that may include personal data”, col. 52, lines 57-62 “a list of the privacy-related attributes … relates to a privacy assessment standard”), wherein the one or more data categories associated with the set of data processing activity components are determined based on the one or more mappings (col. 52, 19-25 “analyzes the computer code to determine a plurality of privacy-related attributes … the types of personal information the computer code collects and/or accesses”);
based on the set of data processing activity components, providing, for display within a graphical user interface, a data processing activity component from the set of data processing activity components (col. 52, lines 52-64 “display to the user a list of the privacy-related attributes related to the computer code”); and
based on the one or more data categories, providing, for display within the graphical user interface, a data category indicating one or more data types or one or more data processing purpose types represented in the set of data processing activity components (col. 56, lines 26-30 “display … a list of the attributes related to … a privacy assessment standard”, see e.g. Fig. 20B, 2035).
Barday does not explicitly disclose:
using a detector specification comprising one or more mappings.
Schwarzbauer teaches:
using a detector specification comprising one or more mappings (par. [0193] “a vulnerable library identifiers list 722, containing identifiers for all libraries containing the vulnerable APIs”).
It would have been obvious before the effective filing date of the claimed invention to Use a detector specification comprising mappings. Those of ordinary skill in the art would have been motivated to do so for “fast and efficient lookup” of the vulnerable data accesses (see e.g. Schwarzbauer par. [0193]).
Claims 2, 12 and 17: Barday and Schwarzbauer teach claims 1, 11 and 16, further comprising providing, for display within the graphical user interface, the data processing activity component by displaying software development kit (SDK) components, application programming interface (API) components, or function call components present within the application code (col. 56, lines 13-23 “third party software (e.g., libraries, SDKs)”).
Claim 3: Barday and Schwarzbauer teach the computer-implemented method of claim 1, further comprising providing, for display within the graphical user interface, the data category indicating the one or more data types by displaying one or more of location data, cookie data, camera data, computing device data, demographic data, hit-level data, device usage data, and/or personal identifiable information data processed within the application code (e.g. col. 56, lines 13-23 “location-based services … tracking (e.g., cookies) … IP address”).
Claim 4: Barday and Schwarzbauer teach the computer-implemented method of claim 1, further comprising providing, for display within the graphical user interface, the data category indicating the one or more data processing purpose types by displaying an application function category, an analytics category, a digital advertisement targeting category, a data aggregation category, or a debugging category (col. 40, lines 55-63 “displays … the purpose of the campaign … to bill appropriately, manage against quotas, and run analytics”).
Claim 5: Barday and Schwarzbauer teach the computer-implemented method of claim 1, further comprising providing, for display within the graphical user interface, the data category by displaying a source for a data processing activity component from the set of data processing activity components, wherein the source comprises an owner entity or a developer for the data processing activity component (col. 7, lines 49-51 “display a heading indicative of the source of the personal data”).
Claims 6 and 14: Barday and Schwarzbauer teach claims 1 and 11, further comprising: :
receiving, within the graphical user interface, a user interaction with a selectable element for the displayed data category (col. 40, lines 8-10 “a filter tool … Filters 1545”); and
based on the user interaction with the selectable element, displaying one or more data processing activity components, from the application code, that correspond to the displayed data category (col. 40, lines 8-10 “to display only the campaigns having certain information associated with them”).
Claims 7 and 15: Barday and Schwarzbauer teach claims 1, 11 and 16, further comprising:
receiving data processing activity component modifications or data category modifications detected between the application code and an updated version of the application code, wherein the data processing activity component modifications comprise an addition or removal of one or more data processing activity components or the data category modifications comprise an addition or removal of one or more data categories (col. 55, lines 24-31 “analyze the computer code … present the user with a list of differences between the obtained instance of computer code and the previous assessed version … attributes that have … been added”); and
providing, for display within the graphical user interface, the data processing activity component modifications or the data category modifications (col. 55, lines 24-31 “analyze the computer code … present the user with a list of differences between the obtained instance of computer code and the previous assessed version … attributes that have … been added”).
Claim 8: Barday and Schwarzbauer teach the computer-implemented method of claim 7, further comprising providing, for display within the graphical user interface, a flagging element associated to a display of the data processing activity component to indicate the data processing activity component modifications or to a display of the data category to indicate the data category modifications (fig. 20B, 2035).
Claim 13: Barday and Schwarzbauer teach the non-transitory computer-readable medium of claim 11, wherein the operations further comprise determining the data processing activity component modifications between the first version of the input application code and the second version of the input application code by identifying an addition or removal of a data processing activity component between the set of detected data processing activity components and the additional set of detected data processing activity components (col. 55, lines 24-31 “analyze the computer code … present the user with a list of differences between the obtained instance of computer code and the previous assessed version … attributes that have … been added”).
Claim 18: Barday and Schwarzbauer teach the system of claim 17, wherein the processing hardware is configured to cause the system to determine the data categories for the one or more data processing activity components by:
identifying a data type corresponding to a data processing activity component from the one or more data processing activity components, wherein the data type comprises location data, cookie data, camera data, computing device data, demographic data, hit-level data, device usage data, or personal identifiable information data (e.g. col. 56, lines 13-23 “location-based services … tracking (e.g., cookies) … IP address”); and
utilizing the data type to assign the data processing activity component with a data category (col. 52, 19-25 “analyzes the computer code to determine a plurality of privacy-related attributes … the types of personal information the computer code collects and/or accesses”).
Claim 19: Barday and Schwarzbauer teach the system of claim 17, wherein the processing hardware is configured to cause the system to determine the data categories for the one or more data processing activity components by:
identifying a data processing purpose type corresponding to a data processing activity component from the one or more data processing activity components, where the data processing purpose type comprises utilization for application function, analytics, digital advertisement targeting, data aggregation, or debugging (col. 40, lines 55-63 “displays … the purpose of the campaign … to bill appropriately, manage against quotas, and run analytics”); and
utilizing the data processing purpose type to assign the data processing activity component with a data category (col. 40, lines 55-63 “displays … the purpose of the campaign … to bill appropriately, manage against quotas, and run analytics”).
Claim 20: Barday and Schwarzbauer teach the system of claim 17, wherein the processing hardware is configured to cause the system to determine data categories for the one or more data processing activity components by:
determining a first data category associated with a first set of data processing activity components from the one or more data processing activity components grouped by a first data type (col. 52, 19-25 “analyzes the computer code to determine a plurality of privacy-related attributes … the types of personal information the computer code collects and/or accesses”); and
determining a second data category associated with a second set of data processing activity components from the one or more data processing activity components grouped by a second data type (col. 52, 19-25 “analyzes the computer code to determine a plurality of privacy-related attributes … the types of personal information the computer code collects and/or accesses”).
Claim Rejections - 35 USC § 103
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 (i.e., changing from AIA to pre-AIA ) 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.
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.
Claim(s) 9-10 is/are rejected under 35 U.S.C. 103 as being unpatentable over US 11,025,675 to Barday et al. (Barday) in view of US 2022/0156383 to Schwarzbauer et al. (Schwarzbauer)in view of US 2018/0276103 to Woulfe et al. (Woulfe).
Claim 9: Barday and Schwarzbauer teach the computer-implemented method of claim 1, but do not explicitly teach:
providing, for display within a development application graphical user interface presenting the application code, an indicator locating the data processing activity component within the application code.
Woulfe teaches:
providing, for display within a development application graphical user interface presenting the application code, an indicator locating a data processing activity component within the application code (par. [0053] “a line … highlighted as potentially buggy … The buggy code 122b … can be displayed”, see e.g. Fig. 1c).
It would have been obvious at the time of filing to display an indicator locating the data processing activity component within the application code. Those of ordinary skill in the art would have been motivated to do so as a known means of communicating information about problematic code which would have produced only the expected results.
Claim 10: Barday, Schwarzbauer and Woulfe teach the computer-implemented method of claim 1, further comprising providing, for display within a development application graphical user interface presenting the application code, an indicator flagging a portion of code from the application code as part of the data category (Woulfe par. [0053] “a line … highlighted”, see e.g. Fig. 1c).
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JASON D MITCHELL whose telephone number is (571)272-3728. The examiner can normally be reached Monday through Thursday 7:00am - 4:30pm and alternate Fridays 7:00am 3: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, Lewis Bullock can be reached at (571)272-3759. 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.
/JASON D MITCHELL/ Primary Examiner, Art Unit 2199
Prosecution Insights