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 Preliminary Amendment
Applicant’s preliminary amendment dated 2/27/2024, amending the specification, has been fully considered and is entered.
Information Disclosure Statement
The information disclosure statement (IDS) submitted on 8/06/2025 is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
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-9 and 14-20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Jones et al. (US 20210279363) in view of Shoavi et al. (US 20160246594).
Regarding claims 1 and 15, Jones teaches: A non-transitory computer-readable medium storing computer-executable instructions / A method comprising: generating, by computing hardware, a first application interface (API) call over a network to a remote computing system (application code includes API calls made by the code to a mobile application on a mobile device par. 0257) to request a list of software development kits (SDKs) providing functionality for a mobile application (Application privacy analysis system may have, or may access, one or more third-party SDK databases par. 0260); receiving, by the computing hardware and from the remote computing system, the list of SDKs over the network (the Application Privacy Analysis system accesses the SDK databases which contain information about known development tools that may have been used to develop the application under analysis par. 0260), wherein the list of SDKs comprises a first SDK associated with a first functionality category (an SDK in the SDK database corresponding to a vendor and functionality token par. 0009 and claim 15) and a second SDK associated with a second functionality category (a second SDK in the SDK database corresponding to a second functionality token par. 0010 and claim 15); causing, by the computing hardware, display of a consent interface within the mobile application (displaying, via the interaction interface, one or more pieces of information regarding the consent par. 0221).
Jones does not explicitly teach a first or second input element for receiving consent for a first and second functionality category, and allowing/blocking a first and second SDK based on the inputs.
However, Shoavi teaches: wherein the consent interface comprises: a first input element configured for receiving consent for the first functionality category, and a second input element configured for receiving consent for the second functionality category (the GUI displays information regarding an application program for a mobile computing device wherein the application program utilizes a software component that is integrated into the application program, wherein the GUI displays one or more enable/disable function buttons par. 0025); receiving, by the computing hardware and via the first input element, first input indicating the consent for the first functionality category (user interacting with the one or more enable/disable function buttons, in this case the enable button par. 0025); receiving, by the computing hardware and via the second input element, second input indicating a lack of the consent for the second functionality category (user interacting with the one or more enable/disable function buttons, in this case the disable button par. 0025); responsive to the first input, allowing, by the computing hardware, first functionality provided by the first SDK to operate within the mobile application (in response to the interaction, updating modifiable configurations of the application program, distributing the configurations, and selectively enabling/disabling the function par. 0025); and responsive to the second input, generating, by the computing hardware, a second API call to block the second SDK from initiating second functionality operating for the mobile application (in response to the interaction, updating modifiable configurations of the application program, including an API return value that provides full disablement of the function par. 0025 and 0045).
It would have been prima facie obvious to one of ordinary skill in the art prior to the effective filing date of the application to combine the teachings of Jones with the teachings of Shoavi since the enable/disable buttons of Shoavi would enhance the teachings of Jones by allowing for selective enabling/disabling of one or more functions during runtime of the application program without having to re-deploy the program.
Regarding claims 2 and 16, Jones teaches: logging the first input and the second input on at least one of the remote computing system or the computing hardware (consent receipt management system may utilize recordation of one or more consent receipts par. 0220).
Regarding claims 3 and 17, Jones teaches: wherein after logging the first input and the second input, the method further comprises: detecting, by the computing hardware, a user interacting with the mobile application (confirming receipt of valid consent par. 0211); and responsive to detecting the user interacting with the mobile application: retrieving, by the computing hardware, the first input and the second input (the system may be configured to confirm receipt of valid consent in association with a unique identifier par. 0211);
Jones does not explicitly teach a first or second input that allows or blocks SDK functionality.
However, Shoavi teaches: responsive to the first input, allowing, by the computing hardware, the first functionality provided by the first SDK to operate within the mobile application (in response to the interaction, updating modifiable configurations of the application program, distributing the configurations, and selectively enabling/disabling the function par. 0025); and responsive to the second input, generating, by the computing hardware, a third API call to block the second SDK from initializing the second functionality operating for the mobile application (selective full disablement of the software component, wherein the one or more functions are functions defined in an API of the software component invoked the program when utilizing the software component par. 0008).
It would have been prima facie obvious to one of ordinary skill in the art prior to the effective filing date of the application to combine the teachings of Jones with the teachings of Shoavi since the enable/disable buttons of Shoavi would enhance the teachings of Jones by allowing for selective enabling/disabling of one or more functions during runtime of the application program without having to re-deploy the program.
Regarding claims 4 and 18, Jones teaches: wherein the list of SDKs comprises a third SDK associated with a third functionality category (an SDK in the SDK database corresponding to a vendor and functionality token par. 0009 and claim 15).
Jones does not explicitly teach consent for functionality.
However, Shoavi teaches: determining, by the computing hardware, that consent for the third functionality category is not required (some OS services may require permission to be utilized while other services may not require any permissions par. 0050); and responsive to determining the consent for the third functionality category is not required, causing, by the computing hardware, display of the consent interface within the mobile application without a third input element configured for receiving the consent for the third functionality category (the GUI displays information regarding an application program for a mobile computing device wherein the application program utilizes a software component that is integrated into the application program, wherein the GUI displays one or more enable/disable function buttons par. 0025).
It would have been prima facie obvious to one of ordinary skill in the art prior to the effective filing date of the application to combine the teachings of Jones with the teachings of Shoavi since the enable/disable buttons of Shoavi would enhance the teachings of Jones by allowing for selective enabling/disabling of one or more functions during runtime of the application program without having to re-deploy the program.
The Examiner would like to note that claim 18 differs from claim 4 by claiming a second SDK rather than a third SDK but this does not substantially change the reasonings/rationale for rejection.
Regarding claim 5, Jones teaches: determining a location of at least one of the computing hardware or a user of the mobile application (Third-party SDK may use or access device component privacy permissions which include access to location par. 0266);
Jones does not explicitly teach consent for functionality based on location.
However, Shoavi teaches: determining that the consent for the third functionality category is not required based on the location (the user may provide the navigation app with the suitable location permissions, which may also allow an SDK used by the navigation app to use the location services par. 0044).
It would have been prima facie obvious to one of ordinary skill in the art prior to the effective filing date of the application to combine the teachings of Jones with the teachings of Shoavi since the enable/disable buttons of Shoavi would enhance the teachings of Jones by allowing for selective enabling/disabling of one or more functions during runtime of the application program without having to re-deploy the program.
Regarding claims 6 and 19, Shoavi teaches: wherein the second API call to block the second SDK from initiating the second functionality performs at least one of setting a consent flag that indicates to the second SDK not to initialize or directing preventing the second SDK from initializing (the GUI displays one of more enable/disable function buttons configured to indicate enablement or disablement of one or more functions associated with the software component, and in response to a user interacting with the one or more enable/disable buttons, modifiable configurations of the application program are updated par. 0025).
It would have been prima facie obvious to one of ordinary skill in the art prior to the effective filing date of the application to combine the teachings of Jones with the teachings of Shoavi since the enable/disable buttons of Shoavi would enhance the teachings of Jones by allowing for selective enabling/disabling of one or more functions during runtime of the application program without having to re-deploy the program.
The Examiner would like to note that, while not being exactly the same, claims 6 and 19 have functionality which does not change depending on what API call or SDK is being blocked, therefore they are rejected under the same reasoning and rationale.
Regarding claims 7 and 20, Shoavi teaches wherein the list of SDKs comprises a third SDK, and the method further comprises: causing, by the computing hardware, display of the consent interface within the mobile application, wherein the consent interface comprises a third input element configured for receiving consent for the third SDK (GUI displaying one or more enable/disable function buttons for one or more functions par. 0025); receiving, by the computing hardware and via the third input element, third input indicating a lack of the consent for the third SDK (user interacting with the one or more enable/disable buttons par. 0025); and responsive to the third input, generating, by the computing hardware, a third API call to block the third SDK from initiating third functionality operating for the mobile application (modifiable configurations of the application program are updated par. 0025).
It would have been prima facie obvious to one of ordinary skill in the art prior to the effective filing date of the application to combine the teachings of Jones with the teachings of Shoavi since the enable/disable buttons of Shoavi would enhance the teachings of Jones by allowing for selective enabling/disabling of one or more functions during runtime of the application program without having to re-deploy the program.
The Examiner would like to note that claims 7 and 20, while not being exactly the same, have the same functionality, and as such are rejected under the same reasoning/rationale.
Regarding claim 8, Jones teaches: wherein, the processing device is configured to execute the instructions and thereby perform operations comprising: decompiling a software application to produce application code for the software application (Decompiler Module used to deconstruct an acquired application for analysis and reduce an application to source code, assembly language, machine code, and/or some other interpretation of functions of the application par. 0255); scanning the application code to identify at least one of non-native functionality, a non-native attribute, or a non-native characteristic of the application code (Static Privacy Analysis System scans applications and Third-Party SDK for various privacy related functions, attributes, and characteristics par. 0265); accessing a repository containing data on known third-party software development kits (SDKs) (Application privacy analysis system has access to one or more third-party SDK databases par. 0260); identifying, based on the data in the repository, at least one of known functionality, a known attribute, or a known characteristic that matches at least one of the non-native functionality, the non-native attribute, or the non-native characteristic (a module determines a first category for a first functionality token using a mapping of functionality tokens to categories and a second category for a second functionality token using the mapping of functionality tokens to categories par. 0009 and claim 15); assigning a functionality category to at least one of the non-native functionality, the non-native attribute, or the non-native characteristic (a module determines functionality token and mapping of functionality tokens to categories par. 0009 and claim 15); and storing, in a second repository, an indication of the source SDK and the functionality category for the software application (Application privacy analysis system has access to one or more third-party SDK databases par. 0260).
Jones does not explicitly teach determining a source SDK based on a known functionality, attribute, or characteristic.
However, Shoavi teaches: determining, based on at least one of the known functionality, the known attribute, or the known characteristic, a source SDK for at least one of the non-native functionality, the non-native attribute, or the non-native characteristic (a code or executable of a software component may be parsed to identify usages of services of an operating system par. 0059);
It would have been prima facie obvious to one of ordinary skill in the art prior to the effective filing date of the application to combine the teachings of Jones with the teachings of Shoavi since the enable/disable buttons of Shoavi would enhance the teachings of Jones by allowing for selective enabling/disabling of one or more functions during runtime of the application program without having to re-deploy the program.
Regarding claim 9, Jones teaches: wherein the software application comprises a mobile application for a mobile device (the system may identify one or more SDKs configured on a mobile device par. 0052).
Regarding claim 14, Shoavi teaches: wherein the operations further comprise generating, based on the indication of the source SDK and the functionality category for the software application, a consent SDK that is incorporated into the software application and is configured to: cause display of a consent interface within the software application, wherein the consent interface comprises an input element configured for receiving consent for the functionality category, receive, via the input element, an input indicating a lack of the consent for the functionality category, and responsive to the input, generating an application programming interface call to block the source SDK from initiating functionality operating for the software application (the GUI displays one or more enable/disable function buttons configured to indicate enablement or disablement of one or more functions associated with the software component, and in response to a user interacting with the one or more enable/disable buttons, modifiable configurations of the application program are updated par. 0025 and Fig. 4).
It would have been prima facie obvious to one of ordinary skill in the art prior to the effective filing date of the application to combine the teachings of Jones with the teachings of Shoavi since the enable/disable buttons of Shoavi would enhance the teachings of Jones by allowing for selective enabling/disabling of one or more functions during runtime of the application program without having to re-deploy the program.
Allowable Subject Matter
Claims 10-13 are objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. Chang et al. (US 9703680) which outlines location tracing and automatic updates of an SDK, Jones et al. (US 20200334380) which outlines a privacy analysis system for monitoring communications traffic, and Zhao (US 20140201328) which outlines providing a UI that provides the user a list of allowable operations associated with a remote client application, which may include a native operation supplied by a mobile SDK.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JORDAN SCOTT MOTTER whose telephone number is (703)756-1550. The examiner can normally be reached Monday - Friday 7:30 a.m. - 4:30 p.m..
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, Pierre Vital can be reached at 571-272-4215. 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.
/J.S.M./Examiner, Art Unit 2198
/PIERRE VITAL/Supervisory Patent Examiner, Art Unit 2198
Prosecution Insights