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 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.
Examiner Notes
Examiner cites particular columns and line numbers in the references as applied to the claims below for the convenience of the applicant. Although the specified citations are representative of the teachings in the art and are applied to the specific limitations within the individual claim, other passages and figures may apply as well. It is respectfully requested that, in preparing responses, the applicant fully consider the references in entirety as potentially teaching all or part of the claimed invention, as well as the context of the passage as taught by the prior art or disclosed by the examiner.
Terminal Disclaimer
The terminal disclaimer filed on 10/25/2024 disclaiming the terminal portion of any patent granted on this application which would extend beyond the expiration date of Patent Application 11,614,951 has been reviewed and is accepted. The terminal disclaimer has been recorded.
Allowable Subject Matter
Claims 10 and 17 are objected to as being dependent upon a rejected base claim, but would be allowable if they are rewritten in independent form including all of the limitations of the base claim and any intervening claims.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1, 2, 5-9, 11, 12, 13-16, and 18-20 are rejected under 35 U.S.C. 103 as being unpatentable over Mehta et al. (U.S. PG PUB 2020/0092374) in view Van Den Bergh et al. (U.S. PG PUB 2017/0241798), Jann (U.S. PG PUB 2017/0331915), and Brendle et al. (U.S. PG PUB 2005/0021354).
Regarding claim 1, Mehta teaches a computer-implemented method, comprising:
storing a custom rule script in a mobile application client, wherein the custom rule script executable instructions that extend operation of the mobile application client to validate, locally on the mobile client (see ¶ [0062] “The rule policy can be a file, script, application programming interface (“API”) call, or other instruction to be transmitted to a user device and implemented. The rule policy can be considered a “compliance rule” or instructions for enforcing a compliance rule.”, note: the script is implemented on the user device, thus it is on the local mobile client), data input to the mobile application client (see ¶[0062] “The rule policy can be a file, script, application programming interface (“API”) call, or other instruction to be transmitted to a user device and implemented. The rule policy can be considered a “compliance rule” or instructions for enforcing a compliance rule. This disclosure is not intended to be limited by describing a particular file, instruction, or policy as a compliance rule, as the word can mean any or all of the above. The rule policy can include an identifier that allows an application engine to determine whether it should execute the rule policy or particular rules within the rule policy.” See ¶[0039] “a compliance rule can be configured to be enforced based on input received by the user device”);
while the mobile application client is in an offline mode (see ¶[0078] “Storing the report locally at stage 250 can allow the application to enforce compliance when the user device is offline without losing any data generated as a result of enforcing the compliance rule.”):
Mehta does not expressly disclose, however, Van Den Bergh teaches
a) accepting a user input through the mobile application client to create or modify an object (see ¶[0027] “According to embodiments of the present invention, an input parameter received via the user interface may comprise an optimisation goal selected from a set of optimisation goals for optimising the aircraft performance. For example, an airline may desire all of its aircrafts to operate at optimum fuel efficiency irrespective of the aircraft load or the weather. Other optimisation goals may include but not limited to, minimum runway length, maximum take-off mass, minimum maintenance cost, maximum landing mass, optimum cruise speed, optimum cruise altitude, minimum time to destination, maximum performance (comprises both take-off and landing), optimum obstacle clearance, and the like.”);
c) immediately enforcing the custom rule script locally on the mobile application client to validate the user input upon occurrence of the triggering event, wherein the custom rule script is enforced prior to creating or modifying the object with the user input in local storage of the mobile application client (see ¶[0030] “For example the results may be stored in the form of log files containing information with regards to the steps taken by the calling module to calculate the aircraft performance, the input parameters received through the user interface and the results obtained, or any other information or combination of information thereof. The log files may be analysed offline by the airline to determine whether the system performs according to specification and whether the correct input parameter values were used in the aircraft performance calculation, thereby enabling the airline or other third parties to take appropriate action when necessary.” see ¶[0029] “According to embodiments of the present invention, the calling module may be arranged for validating the input parameter values received via the user interface against predefined numerical limits and aircraft operational limits specified in any one of the data files, executable scripts or configuration files stored in the first database. As a result, human errors may be significantly reduced by performing a validity check on the values or selections received or made prior to performing the aircraft performance calculation, thereby improving the accuracy of the aircraft performance calculated.”);
wherein the object include metadata identifying the custom rule script that was enforced locally (see ¶[0030] “For example the results may be stored in the form of log files containing information with regards to the steps taken by the calling module to calculate the aircraft performance, the input parameters received through the user interface and the results obtained, or any other information or combination of information thereof. The log files may be analysed offline by the airline to determine whether the system performs according to specification and whether the correct input parameter values were used in the aircraft performance calculation, thereby enabling the airline or other third parties to take appropriate action when necessary.” See ¶[0026] “o this end, the configuration files may for example be in a mark-up language, e.g. XML, i.e. a language that does not require a software developer for adaptation of the content. This can enable the airline to easily adapt on demand the information contained therein without the need of a software developer to be present. For example, a performance engineer may adapt the configuration files via the second terminal so that the aircraft performance is always calculated by taking into account additional parameters, such as specific aircraft configuration settings. In another example, a performance engineer may adapt after maintenance or modification of the aircraft via the second terminal one of the configuration files to include the new configuration settings for a specific aircraft.”).
Hence, it would be obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the teachings of Mehta by adapting Van Den Bergh for preventing data corruption and invalid data (see ¶[0032] of Van Den Bergh).
Mehta and Van Den Bergh do not expressly disclose, however, Jann teaches
upon placement of the mobile application client into an online mode, synchronizing (see ¶[0097] “For example, a pull-to-refresh action can be initiated by a user. The architecture 300 can instead automatically synchronize data when the network connectivity becomes available and/or when the application gets to the foreground (e.g., becomes active) and the device has network connectivity.”), from the mobile application client to a mobile application server (see ¶ [0094] “Data synchronization between the server and the local device has two directions: changes made on the device (for example, new, updated, and deleted records) are sent to the back end during flush operations and data changes on the back-end server (for example, changes by other users or by the same user as a consequence of its previous flush) are downloaded to the device during refresh operations. The offline SDK provides these two methods as separate operations (flush and refresh), so the application has the flexibility to implement the optimal data synchronization strategy.’), the object as created or modified in the mobile application client by the validated user input (see ¶ [0097] “In another example, the architecture 300 can automatically synchronize data when a new record is created or an existing one is updated and the device has network connectivity. In another example, the architecture 300 can automatically synchronize data after a certain amount of time and the device has network connectivity.”)
Hence, it would be obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the teachings of Mehta and Van Den Bergh by adapting Jann for improved performance for data access and manipulation for data that is available locally on the offline device (see ¶[0021] of Jann).
Mehta, Van Den Bergh, and Jann do not expressly disclose, however, Brendle teaches (b) determining that the custom rule script is associated with a BeforeSave triggering event, wherein the custom rule script is triqqered by detecting user action on a save option of the mobile application client (see ¶[0166] “The service manager 16 calls the transaction service provider 40's method BEFORE_SAVE to check if the transactional buffer can be saved. This allows checking if the internal state of the non-transaction service provider is ready for being saved. The method BEFORE_SAVE returns false if it is not possible to save the transactional buffer, then the transaction end is aborted. Thus, the BEFORE_SAVE method has a BOOLEAN return parameter. BEFORE_SAVE takes a Boolean as an input rejected. The transactional service provider 16 can prevent the following save and commit operations by setting the REJECTED parameter to a non-initial value (i.e., to "true"). The method BEFORE_SAVE is called within the service manager 16's sequence of operations triggered by the front-end application 12's SAVE method.”), and performed before the user input is committed to persistence (see ¶[0186] “he BEFORE_SAVE method of the transaction service provider 40 enables all participating service providers to declare if they are ready for saving the transactional buffer. The SAVE method of the transaction service provider 40 finally triggers service manager 17 to save the transactional buffer to the back end database 24.”),
Hence, it would be obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the teachings of Mehta, Van Den Bergh, and Jann by adapting Brendle to receives notifications on the various states of a transaction between service manager, another non-transaction service provider to check if the transactional buffer can be saved (see ¶[0166] of Brendle).
Regarding claim 2, Mehta teaches further comprising: before entering the offline mode:
a) parsing the custom rule script to identify a data set accessed by a query in the custom rule script (see ¶ [0050] “The first compliance engine can parse the information in the object file and compare that information with the condition specified by the first compliance rule. For example, the first compliance rule can specify that if the operating system of the user device is modified, certain functionality of the first application should be limited. The first compliance engine can parse the data object to determine whether the operating system has been modified and compare that to the requirement of the compliance rule.”).
Mehta does not expressly disclose, however, Van Den Bergh teaches
b) loading the data set into the mobile application client (see ¶[0028] “According to embodiments of the present invention, the calling module may comprise a business logic module arranged for selecting, based on the optimisation goal, a set of input parameters to be varied within an applicable range by the calculation engine for optimising the aircraft performance calculation towards the optimisation goal. For example, the predetermined rules may be an optimisation function arranged for varying within a predefined range at least some of the input parameters.”); wherein immediately enforcing the custom rule script to validate the user input further comprises executing the custom rule script to cause the query to be completed immediately from the data set in the mobile application client, without delay for access to a server (see ¶ [0061] “According to embodiments of the present invention, the system 10 may further comprise a test module (not shown) which is accessible via the second terminal 18 to enable the operator to validate configuration files or settings, or adaptations thereof, and/or to test the accuracy and overall performance of the calling module 12 and calculation engine 26. The operator may supply via the second terminal 18 known performance values to be calculated by the calling module 12 and compare the calculated aircraft performance with expected results so as to validate the configuration files or settings, or adaptations thereof, and/or to determine the performance of the system 10.”).
Hence, it would be obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the teachings of Mehta by adapting Van Den Bergh for preventing data corruption and invalid data (see ¶[0032] of Van Den Bergh).
Regarding claim 3, Mehta teaches further comprising, prior to storing the custom rule script in the mobile application client (see ¶[0062] “The rule policy can be a file, script, application programming interface (“API”) call, or other instruction to be transmitted to a user device and implemented. The rule policy can be considered a “compliance rule” or instructions for enforcing a compliance rule. This disclosure is not intended to be limited by describing a particular file, instruction, or policy as a compliance rule, as the word can mean any or all of the above. The rule policy can include an identifier that allows an application engine to determine whether it should execute the rule policy or particular rules within the rule policy.”) receiving the custom rule script because a specific user account that is associated with the mobile application client (see ¶ [0066] “The compliance rule can be transmitted to the application at stage 230. Although FIG. 2 shows that the management server transmits the compliance rule to the application, the rule can be transmitted by another server at the direction of the management server. For example, an application server can provide support for the application and provide a settings endpoint that the application accesses from time to time. The application server can send the compliance rule on behalf of the management server at stage 230, in an example.”) has a characteristic of user accounts for which the mobile application client is to enforce the custom rule script, wherein the characteristic describes (i) a geographic location for which the custom rule applies to transactions (see ¶[0072] “The compliance engine can query the operating system of the user device to determine relevant information, such as the location of the device, the version of the operating system, a listing of applications installed on the device, and any other relevant information.”) or (ii) a business role for which the custom rule applies to the business role.
Regarding claim 5, Mehta does not expressly disclose, however, Van Den Bergh teaches further comprising implementing custom functionality for a first role or location using the custom rule script that is distinct from functionality for a second role or location on one build of the mobile application client (see ¶[0029] “According to embodiments of the present invention, the calling module may be arranged for validating the input parameter values received via the user interface against predefined numerical limits and aircraft operational limits specified in any one of the data files, executable scripts or configuration files stored in the first database. As a result, human errors may be significantly reduced by performing a validity check on the values or selections received or made prior to performing the aircraft performance calculation, thereby improving the accuracy of the aircraft performance calculated.”).
Hence, it would be obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the teachings of Mehta by adapting Van Den Bergh for preventing data corruption and invalid data (see ¶[0032] of Van Den Bergh).
Regarding claim 6, Mehta teaches further comprising executing the custom rule script with the mobile application client (see ¶ [0025] “The compliance rule can be executed by the application engine. In one example, the application engine can check an identifier to determine whether a particular compliance rule is intended for that particular application engine rather than one executing as part of a different application.”) operating in the offline mode (see ¶ [0033] “In an example, a compliance rule can limit features or functionality of an application based on the user device being “offline.””).
Mehta and Van Den Bergh do not expressly disclose, however, Jann teaches
to conditionally hide the field of the object in a graphical user interface, or conditionally hide the field of the object in a graphical user interface in response to satisfaction of a condition (see ¶ [0121] “The application may contain features that require Internet connection to work, and cannot be substituted by simple UI logic (for example, complex business logic with potential access to other data sources and Google Maps integration). The architecture 300 can be used to disable or hide these features while there is no connectivity.”).
Hence, it would be obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the teachings of Mehta and Van Den Bergh by adapting Jann for improved performance for data access and manipulation for data that is available locally on the offline device (see ¶[0021] of Jann).
Regarding claim 7, Mehta teaches further comprising displaying results of the custom rule script in a graphical user interface of the mobile application client in response to the user input while the mobile application client is operating in the offline mode (see ¶ [0077] “At stage 250, the compliance engine can store a report in a storage location of the user device. The report can include a description of the compliance rule that was evaluated at stage 240, a description of the result of the evaluation (i.e., whether the compliance rule was satisfied or not), and a description of any actions performed at stage 245. The report can be a file that includes this information.”).
Regarding claim 8, Mehta teaches a processor; a memory operably connected to the processor, and a non-transitory computer-readable medium operably connected to the processor and memory and storing computer-executable instructions (see ¶ [0020] processor, memory and storage media) that when executed by at least the processor cause the computing system to:
store a custom rule script in a mobile application client, wherein the custom rule comprise executable instructions that extend operation of the mobile application client to validate, locally on the mobile application client (see ¶ [0062] “The rule policy can be a file, script, application programming interface (“API”) call, or other instruction to be transmitted to a user device and implemented. The rule policy can be considered a “compliance rule” or instructions for enforcing a compliance rule.”, note: the script is implemented on the user device, thus it is on the local mobile client), data input to the mobile application client (see ¶[0062] “The rule policy can be a file, script, application programming interface (“API”) call, or other instruction to be transmitted to a user device and implemented. The rule policy can be considered a “compliance rule” or instructions for enforcing a compliance rule. This disclosure is not intended to be limited by describing a particular file, instruction, or policy as a compliance rule, as the word can mean any or all of the above. The rule policy can include an identifier that allows an application engine to determine whether it should execute the rule policy or particular rules within the rule policy.” See ¶[0039] “a compliance rule can be configured to be enforced based on input received by the user device”);
place the mobile application into an offline mode (see ¶[0078] “Storing the report locally at stage 250 can allow the application to enforce compliance when the user device is offline without losing any data generated as a result of enforcing the compliance rule.”);
while the mobile application client is in the offline mode (see ¶[0078] “Storing the report locally at stage 250 can allow the application to enforce compliance when the user device is offline without losing any data generated as a result of enforcing the compliance rule.”).
Mehta does not expressly disclose, however, Van Den Bergh teaches
enforce the custom rule script (see ¶[0029] “According to embodiments of the present invention, the calling module may be arranged for validating the input parameter values received via the user interface against predefined numerical limits and aircraft operational limits specified in any one of the data files, executable scripts or configuration files stored in the first database. As a result, human errors may be significantly reduced by performing a validity check on the values or selections received or made prior to performing the aircraft performance calculation, thereby improving the accuracy of the aircraft performance calculated.”), locally on the mobile application client to validate a user input through the mobile application client to create or modify an object (see ¶[0027] “According to embodiments of the present invention, an input parameter received via the user interface may comprise an optimisation goal selected from a set of optimisation goals for optimising the aircraft performance. For example, an airline may desire all of its aircrafts to operate at optimum fuel efficiency irrespective of the aircraft load or the weather. Other optimisation goals may include but not limited to, minimum runway length, maximum take-off mass, minimum maintenance cost, maximum landing mass, optimum cruise speed, optimum cruise altitude, minimum time to destination, maximum performance (comprises both take-off and landing), optimum obstacle clearance, and the like.”),
wherein the custom rule is enforced in response to the user input attempting to modify a field value of the object (see ¶[0050] “Furthermore, the calling module 12 may be arranged so that prior to performing the calculation it checks whether the values supplied as input parameters are within expected numerical ranges by comparing the values received with values stored in any of the files in the first database. The calling module 12 may be further arranged to alert the user in the case of the values not being within the expected range, thereby preventing mistakes propagating into the aircraft performance calculations.”),
wherein the object includes metadata identifying the custom rule script that was enforced locally (see ¶[0030] “For example the results may be stored in the form of log files containing information with regards to the steps taken by the calling module to calculate the aircraft performance, the input parameters received through the user interface and the results obtained, or any other information or combination of information thereof. The log files may be analysed offline by the airline to determine whether the system performs according to specification and whether the correct input parameter values were used in the aircraft performance calculation, thereby enabling the airline or other third parties to take appropriate action when necessary.” See ¶[0026] “o this end, the configuration files may for example be in a mark-up language, e.g. XML, i.e. a language that does not require a software developer for adaptation of the content. This can enable the airline to easily adapt on demand the information contained therein without the need of a software developer to be present. For example, a performance engineer may adapt the configuration files via the second terminal so that the aircraft performance is always calculated by taking into account additional parameters, such as specific aircraft configuration settings. In another example, a performance engineer may adapt after maintenance or modification of the aircraft via the second terminal one of the configuration files to include the new configuration settings for a specific aircraft.”).
Hence, it would be obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the teachings of Mehta by adapting Van Den Bergh for preventing data corruption and invalid data (see ¶[0032] of Van Den Bergh).
Mehta and Van Den Bergh do not expressly disclose, however, Jann teaches
upon placement of the mobile application client into an online mode, synchronizing (see ¶[0097] “For example, a pull-to-refresh action can be initiated by a user. The architecture 300 can instead automatically synchronize data when the network connectivity becomes available and/or when the application gets to the foreground (e.g., becomes active) and the device has network connectivity.”), from the mobile application client to a mobile application server (see ¶ [0094] “Data synchronization between the server and the local device has two directions: changes made on the device (for example, new, updated, and deleted records) are sent to the back end during flush operations and data changes on the back-end server (for example, changes by other users or by the same user as a consequence of its previous flush) are downloaded to the device during refresh operations. The offline SDK provides these two methods as separate operations (flush and refresh), so the application has the flexibility to implement the optimal data synchronization strategy.’), the object as created or modified in the mobile application client by the validated user input (see ¶ [0097] “In another example, the architecture 300 can automatically synchronize data when a new record is created or an existing one is updated and the device has network connectivity. In another example, the architecture 300 can automatically synchronize data after a certain amount of time and the device has network connectivity.”);
Hence, it would be obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the teachings of Mehta and Van Den Bergh by adapting Jann for improved performance for data access and manipulation for data that is available locally on the offline device (see ¶[0021] of Jann).
Mehta, Van Den Bergh, and Jann do not expressly disclose, however, Brendle teaches wherein the custom rule script is associated with a BeforeSave triggering event, wherein the custom rule script is triqqered by detecting user action on a save option of the mobile application client (see ¶[0166] “The service manager 16 calls the transaction service provider 40's method BEFORE_SAVE to check if the transactional buffer can be saved. This allows checking if the internal state of the non-transaction service provider is ready for being saved. The method BEFORE_SAVE returns false if it is not possible to save the transactional buffer, then the transaction end is aborted. Thus, the BEFORE_SAVE method has a BOOLEAN return parameter. BEFORE_SAVE takes a Boolean as an input rejected. The transactional service provider 16 can prevent the following save and commit operations by setting the REJECTED parameter to a non-initial value (i.e., to "true"). The method BEFORE_SAVE is called within the service manager 16's sequence of operations triggered by the front-end application 12's SAVE method.”),
and performed before the user input is committed to persistence (see ¶[0186] “he BEFORE_SAVE method of the transaction service provider 40 enables all participating service providers to declare if they are ready for saving the transactional buffer. The SAVE method of the transaction service provider 40 finally triggers service manager 17 to save the transactional buffer to the back end database 24.”),
Hence, it would be obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the teachings of Mehta, Van Den Bergh, and Jann by adapting Brendle to receives notifications on the various states of a transaction between service manager, another non-transaction service provider to check if the transactional buffer can be saved (see ¶[0166] of Brendle).
Regarding claim 9, is a system claim that substantially corresponds with claim 2, therefore, it is rejected for the same reasons as claim 2.
Regarding claim 11, Mehta teaches further comprising a mobile device (see ¶ [0020] “The user device can be any computing device, such as a smartphone, laptop, tablet, personal computer, or workstation”), wherein the non-transitory computer-readable medium further comprises instructions that when executed by at least the processor cause the computing system to execute the mobile application client on the mobile device (see ¶[0020] “The user device can also execute software applications.”).
Regarding claim 12, Mehta teaches wherein the computing system is a mobile device (see ¶ [0020] “The user device can be any computing device, such as a smartphone, laptop, tablet, personal computer, or workstation”), and wherein the non-transitory computer-readable medium further comprises instructions that when executed by at least the processor cause the mobile device to execute the mobile application client (see ¶[0020] “The user device can also execute software applications.”).
Regarding claim 14, Mehta teaches wherein the non-transitory computer-readable medium further comprises instructions that when executed cause the computing system to: determine that a triggering event occurs due to the user input (see ¶ [0028] “Stage 140 can include determining whether the condition specified by the compliance rule (also referred to as “triggering condition”) is present. This stage can be performed directly by the application. In some examples, a compliance rule can specify one or more triggering conditions that, if present, can trigger a remedial action to be performed at stage 150. The remedial action can be performed by the application that was received at stage 110.”); and search a set of custom rules to identify that the custom rule script is associated with the triggering event for the object (see ¶ [0027] “Stage 130 can include executing the application. Executing the application at stage 130 can also include checking for new compliance rules or updating an existing compliance rule. The application can check for new compliance rules by accessing a backend settings endpoint that provides application settings to the user device.”).
Regarding claim 15, is an independent medium claim substantially corresponding to method claim 1, therefore, they are rejected for the same reasons as claim 1.
Regarding claim 16, is a medium claim that substantially corresponds with claim 2, therefore, it is rejected for the same reasons as claim 2.
Regarding claim 18, Mehta teaches wherein the instructions to enforce the custom rule script cause the mobile application client to execute the custom rule script to require that a field of the object be filled (see ¶[0069] “The compliance engine can interpret a compliance rule based on a predetermined or expected format of the compliance rule. For example, the compliance engine can expect a compliance rule to include a first field for an identification of the subject of the compliance rule. This can include a hardware or software entity, a location, a management status, or any other relevant subject. The compliance engine can also expect a second field for a condition indicator that indicates whether the identified subject is required, prohibited, or optional. The compliance engine can further expect a third field for one or more actions to be performed based on comparing the first and second fields to the relevant status of the user device or user. Additionally, in an example, a rule can include an identifier that allows the compliance engine to verify that it should execute the rule.”).
Regarding claim 19, Mehta teaches wherein the instructions to enforce the custom rule script cause the mobile application client to execute the custom rule script to set a value for a field of the object based on a formula expressed in the custom rule script (see ¶[0070] “The data object can include a first field identifying the application, including application versions if applicable. The data object can also include a second field indicating that the application, or the identified versions of the application, prohibit access to enterprise resources. The data object can include a third field specifying that the application should block access to the enterprise resource when the identified application is installed on the user device.”).
Regarding claim 20, Mehta teaches wherein the instructions to enforce the custom rule script cause the mobile application client to execute the custom rule script to set a value for a field of the object based on a query by the custom rule script on a data set stored in the mobile application client (see ¶[0072] “The compliance engine can query the operating system of the user device to determine relevant information, such as the location of the device, the version of the operating system, a listing of applications installed on the device, and any other relevant information. In some examples, the one or more SDKs comprising the compliance engine can include privileges that allow the compliance engine to request such detail from the operating system of the user device, such as by using an API call or other communication protocol.” See ¶ [0073] “Stage 240 can also include comparing the fields of the compliance rule to the data object describing state information of the user device. The compliance engine can determine whether each field of the compliance rule applies, and if so, how it applies”).
Claims 4 and 13 are rejected under 35 U.S.C. 103 as being unpatentable over Mehta et al. (U.S. PG PUB 2020/0092374) in view of Van Den Bergh et al. (U.S. PG PUB 2017/0241798) and Jann (U.S. PG PUB 2017/0331915), and Brendle et al. (U.S. PG PUB 2005/0021354). as applied to claim 1, further in view of Hopkins (U.S. PG PUB 2007/0078950).
Regarding claim 4, Mehta, Van Den Bergh, Jann, and Brendle do not expressly disclose, however, Hopkins teaches
wherein the custom rule script is written in an interpreted programming language (see ¶ [0060] “The functional logic 220 at the remote server 200, in one aspect, is invoked through an underlying application or specification such as a CGI program (including, for example, scripts such as Perl), Java servlet (including, for example, JavaServer Pages, or JSP, technology), daemon, service, system agent, server API solution (including, for example, ISAPI or NSAPI) or any other technique or technology known in the art.”), the method further comprising executing the custom rule script with a script execution engine of the mobile application client when operating in the offline mode (see ¶ [0065] “As depicted in FIG. 7, during the installation phase 500, the executable prepares the client for conducting an offline session by, for example and without limitation, (1) establishing a directory structure in the client's file system (Step 510), (2) downloading navigational markup documents with embedded functional logic (e.g., HTML files with embedded JavaScript code or HTML files and related separate JavaScript files) (Step 520); (3) downloading other miscellaneous installation components such as offline APIs and associated logic as will be discussed below as well as other possible components including, for example, static HTML files, stylesheets, XSL templates, ActiveX controls, system shortcuts, local language components and, if not already available, an XML parser that may be integrated into the web browser (e.g., MSXML Parser) (Step 530).”).
Hence, it would be obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the teachings of Mehta, Van Den Berg, Jann, and Brendle by adapting Hopkins to simulating an online session between the client and a remote server when the client is offline (see ¶ [0037] of Hopkins).
Regarding claim 13 is a system claim that substantially corresponds with claim 4 above, and therefore are rejected for the same reasons.
Response to Arguments
Applicant's arguments filed 1/20/2026 have been fully considered but they are not persuasive.
In regards to 103 rejections, applicants argue the prior arts of record do not disclose the newly amended limitations. Argument is moot due to the new reference examiner has cited.
Applicants further argue A1. Van Den Bergh do not disclose metadata identifying the custom rule script, an assert that Van Den Bergh only disclose external artifacts such as log files or configuration data and are not embedded metadata.
Examiner disagrees. Examiner cited Van Den Bergh, XML files as meta data that is stored in the log files, see ¶[0026].
Applicants further argue A2. Van Den Bergh do not disclose enforcing the custom rule script prior to creating or modifying the object.
Examiner disagrees. In response to applicant's argument, the test for obviousness is not whether the features of a secondary reference may be bodily incorporated into the structure of the primary reference; nor is it that the claimed invention must be expressly suggested in any one or all of the references. Rather, the test is what the combined teachings of the references would have suggested to those of ordinary skill in the art. See In re Keller, 642 F.2d 413, 208 USPQ 871 (CCPA 1981).
In this case Mehta teaches enforcing the custom rule script, see ¶ [0030]. Van Den Bergh teaches validating the input parameter values received via the user interface against predefined numerical limits and aircraft operational limits specified in any one of the data files, executable scripts or configuration files stored in the first database. As a result, human errors may be significantly reduced by performing a validity check on the values or selections received or made prior to performing the aircraft performance calculation, thereby improving the accuracy of the aircraft performance calculated, see ¶[0029].
Examiner used prior arts, Mehta, Van Den Bergh in the rejection to disclose offline mode and validation checks. Applicant is reminded the rejection is based on a combination of references and not any single reference alone. It is the combined teachings that discloses the claimed invention.
Applicants further argue A3. Van Den Bergh do not disclose a triggering event based on attempted field modification is not taught.
Examiner disagrees. The claim limitation appears to be removed and new prior art was cited to disclose the new limitation.
Applicants further argue A4.Van Den Bergh do not disclose creation or modification of an object while offline.
In response to applicant's argument, the test for obviousness is not whether the features of a secondary reference may be bodily incorporated into the structure of the primary reference; nor is it that the claimed invention must be expressly suggested in any one or all of the references. Rather, the test is what the combined teachings of the references would have suggested to those of ordinary skill in the art. See In re Keller, 642 F.2d 413, 208 USPQ 871 (CCPA 1981).
In this case Mehta teaches offline mode, see ¶[0078] enforce compliance in offline mode without loosing data.
Van Den Bergh also teaches accepting user input through the mobile application to create of modify an object, see ¶[0027] which discloses an input parameter by a user for an aircraft, for example, fuel, the mode of the device may be in offline mode, see ¶[0035].
Applicants argue B. Teaching away by Jann and states that Jann teaches away from the invention because it does not support offline mode and does not do any validation checks in offline mode. Applicant states one paragraph regarding a store not having any kind of business logic in offline mode.
Examiner disagrees. In response to applicant's argument, the test for obviousness is not whether the features of a secondary reference may be bodily incorporated into the structure of the primary reference; nor is it that the claimed invention must be expressly suggested in any one or all of the references. Rather, the test is what the combined teachings of the references would have suggested to those of ordinary skill in the art. See In re Keller, 642 F.2d 413, 208 USPQ 871 (CCPA 1981).
Jann teaches offline mode and handling synchronizing, see ¶[0097], thus it does not each away from the invention. Applicant is citing a specific embodiment or example, but does not read the reference in its entirety. Jann also discloses offline mode see ¶[0004] and ¶[0005], and validation checks in offline mode, see ¶[0128]. Examiner used prior arts, Mehta, Van Den Bergh in the rejection to disclose offline mode and validation checks. Applicant is reminded the rejection is based on a combination of references and not any single reference alone. It is the combined teachings that discloses the claimed invention.
Applicants argue C. Non analogous art, and submits that Van Den Bergh is directed to aircraft performance and is non-analogous art.
In response to applicant's argument that Van Den Bergh is nonanalogous art, it has been held that a prior art reference must either be in the field of the inventor’s endeavor or, if not, then be reasonably pertinent to the particular problem with which the inventor was concerned, in order to be relied upon as a basis for rejection of the claimed invention. See In re Oetiker, 977 F.2d 1443, 24 USPQ2d 1443 (Fed. Cir. 1992). In this case, the subject matter is devices in offline mode, Van Den Bergh maybe associated with aircraft, however, the problem at hand, is how to deal with devices in offline mode, and Van Den Bergh addresses these concerns. Thus, it is a reasonable pertinent to the problems of handling offline mode devices.
Van Den Bergh is also in the same field of endeavor, for example, the instant application is relating to mobile applications and software. Van Den Bergh is also dealing with mobile applications and software, see ¶[0066].
Applicants argue D. Deficient rationale to combine and states that improving performance for data access and manipulation for data that is available locally on the offline device is generic and does not explain why one would modify Jann’s offline first synchronization architecture.
Examiner disagrees. The motivation statement states that Mehta, Van Den Bergh is modified to include the features of Jann such as the ability to hide fields of an object, this is an improvement because it prevents data access on the offline device. This is not a generic statement. It is a specific feature and rationale of combining the references.
Applicants argue E. Jann does not disclose to conditionally show or hide the field of the object, and argues Jann teaches disabling entire features not field of an object in a GUI.
Examiner disagrees. Jann teaches that on the condition that certain features like complex business logic that can not be sustained without an internet connection, those features would be disabled. In addition, ¶[0117] disclose a need to hide certain UI elements in the offfline mode to prevent access. These certain UI elements are the fields of an object in a GUI
Support for Amendments and Newly Added Claims
Applicants are respectfully requested, in the event of an amendment to claims or submission of new claims, that such claims and their limitations be directly mapped to the specification, which provides support for the subject matter. This will assist in expediting compact prosecution. MPEP 714.02 recites: “Applicant should also specifically point out the support for any amendments made to the disclosure. See MPEP § 2163.06. An amendment which does not comply with the provisions of 37 CFR 1.121(b), (c), (d), and (h) may be held not fully responsive. See MPEP § 714.” Amendments not pointing to specific support in the disclosure may be deemed as not complying with provisions of 37 C.F.R. 1.121(b), (c), (d), and (h) and therefore held not fully responsive. Generic statements such as “Applicants believe no new matter has been introduced” may be deemed insufficient.
Interview Requests
In accordance with 37 CFR 1.133(a)(3), requests for interview must be made in advance. Interview requests are to be made by telephone (571-270-7848) call or FAX (571-270-8848). Applicants must provide a detailed agenda as to what will be discussed (generic statement such as “discuss §102 rejection” or “discuss rejections of claims 1-3” may be denied interview). The detail agenda along with any proposed amendments is to be written on a PTOL-413A or a custom form and should be faxed (or emailed, subject to MPEP 713.01.I / MPEP 502.03) to the Examiner at least 5 business days prior to the scheduled interview. Interview requests submitted within amendments may be denied because the Examiner was not notified, in advance, of the Applicant Initiated Interview Request and due to time constraints may not be able to review the interview request to prior to the mailing of the next Office Action.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Totale et al. (U.S. PG PUB 2019/0018953) teaches an event manager executes a multitenant computing platform. The event manager obtains a first domain-specific event indicating a user request to perform operations associated with a particular tenant's domain object. Information for the domain object associated with the domain-specific event is retrieved from a tenant database, the information including a domain object definition and instructions defining its behaviors. A protected event execution environment (sandbox) is generated on the multitenant computing platform implementing restrictions on execution of the domain object's behavior instructions. The restrictions are specific to the combination of the user and the domain object. Execution of the instructions is initiated in the protected event execution environment. A second domain-specific event which indicates a request to modify the domain object information is then obtained, and the modification of the domain object information is initiated in the protected event execution environment.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to CARINA YUN whose telephone number is (571)270-7848. The examiner can normally be reached Mon, Tues, Thurs, 9-4 (EST).
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 call.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Kevin Young can be reached at (571) 270-3180. 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.
Carina Yun
Patent Examiner
Art Unit 2194
/CARINA YUN/Examiner, Art Unit 2194