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 .
DETAILED ACTION
This is in response to Application #18/705,136 filed on 04/26/2024 in which Claims 1-20 are presented for examination.
Status of Claims
Claims 1-20 are pending, of which Claims 1, 2, 3, 4, 5, 18, 19, 20 are rejected under 35 U.S.C. 103 ,Claims 1-20 are rejected under Double Patenting, dependent Claims 6-17 are objected to as being allowable as a whole over prior art if rewritten in independent form including all of the limitations of their base independent claim and any intervening dependent claims.
Applicant’s Most Recent Claim Set of 04/26/2024
Applicant’s most recent claim set of 04/26/2024 is considered to be the latest claim set under consideration by the examiner.
Claim Objections
Regarding Claim 19, this claim is objected to for apparently retaining the Foreign claim structure of its related earlier foreign application, which in this case has the effect under United States claim structure, of disguising an Independent Claim as a Dependent Claim. Currently Claim 19 reads as: “An electronic device, comprising: a memory and a processor; wherein the memory is used to store one or more computer instructions, wherein the one or more computer instructions are executed by the processor to implement a method according to claim 18.”. The examiner construes Claim 19 to be an Independent Claim of an Apparatus Statutory Class with similar limitations as to Method Statutory Class Independent Claim 18.
Appropriate correction is required to rewrite Claim 19 with the appropriate limitations written inline, rather than using a Foreign Style Shorthand, and to no longer attempt to disguise Independent Claim 19 as a dependent claim. Applicant may of course choose to rewrite Claim 19 in the correct appropriate United States Claim Structure, as either an Independent Claim or a Dependent Claim.
Regarding Claim 20, this claim is objected to for apparently retaining the Foreign claim structure of its related earlier foreign application, which in this case has the effect under United States claim structure, of disguising an Independent Claim as a Dependent Claim. Currently Claim 20 reads as: “A computer-readable storage medium, with one or more computer instructions stored thereon, wherein the one or more computer instructions are executed by a processor to implement a method according to claim 18.”. The examiner construes Claim 20 to be an Independent Claim of a Medium Statutory Class with similar limitations as to Method Statutory Class Independent Claim 18.
Appropriate correction is required to rewrite Claim 20 with the appropriate limitations written inline, rather than using a Foreign Style Shorthand, and to no longer attempt to disguise Independent Claim 20 as a dependent claim. Applicant may of course choose to rewrite Claim 20 in the correct appropriate United States Claim Structure, as either an Independent Claim or a Dependent Claim.
Although this issue is not the examiner’s responsibility, applicant might want to keep in mind, that if applicant chooses to maintain both Claims 19 and 20 as independent claims, according to the instant application’s fee worksheet of 02/04/2026 in the File Wrapper, applicant has so far only paid for the basic default of three independent claims, not four. This apparently was caused by the third and fourth independent claims, Claims 19 and 20, having been disguised as dependent claims, even though both Claim 19 and Claim 20 are clearly NOT dependent claims, but rather are improperly written independent claims.
Double Patenting
The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory double patenting rejection is appropriate where the conflicting claims are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on nonstatutory double patenting provided the reference application or patent either is shown to be commonly owned with the examined application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. See MPEP § 717.02 for applications subject to examination under the first inventor to file provisions of the AIA as explained in MPEP § 2159. See MPEP § 2146 et seq. for applications not subject to examination under the first inventor to file provisions of the AIA . A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b).
The filing of a terminal disclaimer by itself is not a complete reply to a nonstatutory double patenting (NSDP) rejection. A complete reply requires that the terminal disclaimer be accompanied by a reply requesting reconsideration of the prior Office action. Even where the NSDP rejection is provisional the reply must be complete. See MPEP § 804, subsection I.B.1. For a reply to a non-final Office action, see 37 CFR 1.111(a). For a reply to final Office action, see 37 CFR 1.113(c). A request for reconsideration while not provided for in 37 CFR 1.113(c) may be filed after final for consideration. See MPEP §§ 706.07(e) and 714.13.
The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The actual filing date of the application in which the form is filed determines what form (e.g., PTO/SB/25, PTO/SB/26, PTO/AIA /25, or PTO/AIA /26) should be used. A web-based eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about eTerminal Disclaimers, refer to www.uspto.gov/patents/apply/applying-online/eterminal-disclaimer.
Claim(s) 1-20 (is/are) of the instant application are rejected on the ground of nonstatutory double patenting as being unpatentable over claim(s) 1-19 of U.S. Patent No. 11,568,069. Although the claims at issue are not identical, they are not patentably distinct from each other because the instant application’s Sister Patent No. 11,568,069’s claims 1-19 anticipate claims 1-20 of the instant application
With respect to claim(s) 1-20 of the instant application, please refer to the table below, which illustrates the anticipatory relationship of the claim limitations at issue:
Instant application
U.S. Patent No. 11,568,069
Claim 1
Claim 1
Claim 2
Claim 2
Claim 3
Claim 3
Claim 4
Claim 4
Claim 5
Claim 1
Claim 6
Claim 5
Claim 7
Claim 6
Claim 8
Claim 7
Claim 9
Claim 8
Claim 10
Claim 9
Claim 11
Claim 10
Claim 12
Claim 11
Claim 13
Claim 12
Claim 14
Claim 13
Claim 15
Claim 14
Claim 16
Claim 15
Claim 17
Claim 16
Claim 18
Claim 17
Claim 19
Claim 18
Claim 20
Claim 19
Prior Art Rejections - 35 USC § 102 and/or 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 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.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102 of this title, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
Claim(s) 1, 2, 3, 4, 18, 19, 20 are rejected under 35 U.S.C. 103 as being unpatentable over Sartor et al US Patent # 9,928,059 in view of Schulman et al US Patent Application Publication # 2017/0034193.
Regarding Claim 1, Sartor et al discloses:
A system of data security protection, comprising:
a security computing sub-system, configured to manage security of developed code to compile the developed code into an installation file corresponding to a target application and a service program for supporting the target application [(Sartor et al Col 2 Lines 6-19; Col 5 Lines 9-17; Col 7 Lines 59-67; Col 8 Lines 1-17; Col 10 Lines 59-67; Col 11 Lines 1-15; Fig 3) where Sartor et al teaches a secure application installation and update system, that implements secure error free application installations and updates by automating the process over that of alternatively using a manual process, with multiple automated checks and balances to ensure that both code that it complies and code that it receives already compiled for integration into an instance of an installation script to create fresh installations and code updates on target applications executing on target systems, is securely error free, by so doing the secure application installation and update system also provides an automated program controlled process for servicing existing installations of the target applications executing on the target systems to keep their installed applications up-to-date];
a data exchange sub-system, configured to manage data communication of the target application or the service program with rest of World, RoW [(Sartor et al Col 5 Lines 60-67; Col 6 Lines 1-5; Col 7 Lines 59-67; Fig 1 Items 130, 128, 104, 102, 150) where Sartor et al teaches an application agent in combination with network site hosts, networks to user devices, and networks to developer systems that manages data communication with the target application and the rest of the world, which would be everything networked to the target application]; and
a security sandbox sub-system, configured to manage traffic data associated with the target application.
Sartor et al does not appear to explicitly disclose:
a security sandbox sub-system, configured to manage traffic data associated with the target application
However, Schulman et al discloses:
a security sandbox sub-system, configured to manage traffic data associated with the target application [(Schulman et al Par 55 Lines 1-20; Fig 1B) where Schulman et al teaches the use of a security sandbox system to manage or reroute application traffic data that is suspected of being an intrusion or malicious into an isolated environment for protection of the application and further study as to the nature of the suspected threat].
Sartor et al and Schulman et al are analogous art because they are from the “same field of endeavor” and are from the same “problem-solving area”. Namely, they are both from the field of “information security”.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Sartor et al and the teachings of Schulman et al by providing a security sandbox system to manage or reroute application traffic data that is suspected of being an intrusion or malicious into an isolated environment for protection of the application and further study as to the nature of the suspected threat as taught by Schulman et al in the teaching described by Sartor et al.
The motivation for doing so would be to increase the usability and flexibility of Sartor et al by providing a security sandbox system to manage or reroute application traffic data that is suspected of being an intrusion or malicious into an isolated environment for protection of the application and further study as to the nature of the suspected threat as taught by Schulman et al in the teaching described by Sartor et al so as to provide an industry standard security procedure for handling communications data that is suspected of being an intrusion or malicious.
Regarding Claim 2, most of the limitations of this claim have been noted in the rejection of Claim 1. Applicant is directed to the rejection of Claim 1 above. In addition, the combination of Sartor et al and Schulman et al discloses:
The system according to claim 1, wherein the security computing sub-system is further configured to: compile the developed code to generate intermediate code; and provide the intermediate code to a code scanning module managed by a trusted partner to determine security of the developed code [(Sartor et al Col 8 Lines 4-17; Fig 1 Items 142, 144, 124, 126) where Sartor et al teaches that the developed code is tested at various stages or intermediate steps, with some executable code compiled and some executable code not yet compiled, and that the test systems managing and performing the task of a code scanning module to determine the security of the developed code can be trusted partners including an application test host, and one or more application hosts, in addition to the application test system].
Regarding Claim 3, most of the limitations of this claim have been noted in the rejection of Claim 2. Applicant is directed to the rejection of Claim 2 above. In addition, the combination of Sartor et al and Schulman et al discloses:
The system according to claim 2, wherein the security computing sub- system is further configured to: obtain a third-party library associated with the developed code; and generate the intermediate code based on the developed code and the third-party library [(Sartor et al Col 8 Lines 4-17; Col 10 Lines 24-31; Fig 1 Items 142, 144, 124, 126) where Sartor et al teaches that the developed code is linked with a third-party library is tested at various stages or intermediate steps, with some executable code compiled and some executable code not yet compiled].
Regarding Claim 4, most of the limitations of this claim have been noted in the rejection of Claim 1. Applicant is directed to the rejection of Claim 1 above. In addition, the combination of Sartor et al and Schulman et al discloses:
The system according to claim 1, wherein the security computing sub- system comprises: a deployment gateway, configured to provide the installation file to an application store or cause the service program to be deployed to a target application platform [(Sartor et al Col 2 Lines 6-19; Col 5 Lines 9-17; Col 7 Lines 59-67; Col 8 Lines 1-17; Col 10 Lines 59-67; Col 11 Lines 1-15; Fig 3) where Sartor et al teaches a secure application installation and update system, that implements secure error free application installations and updates over a development gateway by automating the process over that of alternatively using a manual process, with multiple automated checks and balances to ensure that both code that it complies and code that it receives already compiled for integration into an instance of an installation script to create fresh installations and code updates on target applications executing on target systems, is securely error free, by so doing the secure application installation and update system also provides an automated program controlled process for servicing existing installations of the target applications and executing on the target systems to keep their installed applications up-to-date].
Regarding Claim 18:
It is a method claim corresponding to the system claim of claim 1. Therefore, claim 18 is rejected with the same rationale as applied against claim 1 above.
Regarding Claim 19:
It is a device claim corresponding to the system claim of claim 1. Therefore, claim 19 is rejected with the same rationale as applied against claim 1 above.
Regarding Claim 20:
It is a medium claim corresponding to the system claim of claim 1. Therefore, claim 20 is rejected with the same rationale as applied against claim 1 above.
Claim(s) 5 are rejected under 35 U.S.C. 103 as being unpatentable over Sartor et al US Patent # 9,928,059 in view of Schulman et al US Patent Application Publication # 2017/0034193 and further in view of Nishio US Patent # 8,375,214.
Regarding Claim 5: the combination of Sartor et al and Schulman et al discloses:
The system according to claim 4, wherein the security computing sub-system is further configured to:
The combination of Sartor et al and Schulman et al does not appear to explicitly disclose:
in response to determining that the developed code is secure, generate a signature corresponding to the installation file or the service program.
However, Nishio discloses:
in response to determining that the developed code is secure, generate a signature corresponding to the installation file or the service program [(Nishio Col 23 Lines 17-34) where Nishio teaches that upon determining that installed developed code or structured language is secure, to generate a signature corresponding to the installed developed code or structured language].
Sartor et al and Schulman et al, and Nishio are analogous art because they are from the “same field of endeavor” and are from the same “problem-solving area,”. Namely, they are both from the field of “information security”.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Sartor et al and Schulman et al and the teachings of Nishio by providing an indication that installed developed code or structured language is secure by generating a signature corresponding to the installed developed code or structured language as taught by Nishio in the teaching described by Sartor et al and Schulman et al.
The motivation for doing so would be to increase the usability and flexibility of Sartor et al and Schulman et al, and Nishio by providing an indication that installed developed code or structured language is secure by generating a signature corresponding to the installed developed code or structured language as taught by Nishio in the teaching described by Sartor et al and Schulman et al so as provide an industry standard proof mechanism of a digital signature to indicate that a selection of digital data or code is legitimate.
Allowable Subject Matter – Dependent Claim(s)
Claims 6-17 are objected to as being dependent upon a rejected base claim, but would be allowable as a whole over prior art if rewritten in independent form including all of the limitations of their base independent claim, and any intervening dependent claims.
The following is a statement of reasons for the indication of allowable subject matter.
The closest prior art, as recited, Sartor et al US Patent # 9,928,059 and Schulman et al US Patent Application Publication # 2017/0034193, are also generally directed to various aspects of providing data security protection of a computing application, and the necessary support programs for installing, servicing, and providing secure communication with the computing application. However, Sartor et al or Schulman does not teach or suggest, either singularly or in combination, the particular combination of steps or elements as recited in the dependent Claims 6-17 when also incorporating all of the limitations of their base independent claim and any intervening dependent claims. For example, none of the cited prior art teaches or suggests the steps of:
where the target application or the service program communicates with the data exchange sub-system via a first platform, and the data exchange sub-system is further configured to obtain original data to be exchanged between a first platform and a second platform, process the original data based on a type of the original data to obtain normalized data corresponding to the type, and determine a satisfaction as to a data exchange constraint from the normalized data, where the first platform is a target application platform under jurisdiction of a specific country or region, and the second platform is a target application platform under jurisdiction of another country or region, in accordance with a determination that the normalized data satisfies the data exchange constraint, converting the normalized data into the original data, and performing an exchange of the original data between the first platform and the second platform, where processing the original data includes detecting a format of the original data, the type of the original data comprising a plurality of formats, and obtaining the normalized data by converting a format of the original data into a specified format of the plurality of data formats through format conversion, where a plurality of data channels corresponding to a plurality of types of original data are created between the first platform and the second platform, and processing the original data includes selecting, based on the type of the original data, a data channel corresponding to the type from the plurality of data channels, and providing the original data to the selected data channel for processing, where the target application is a client application, and the security sandbox sub-system is further configured to detect a transmission of user data of a target user from the client application to a server, analyze traffic data of the transmission at different layers of the transmission based on types of the traffic data, and in accordance with a determination that the analysis indicates that the traffic data satisfies a data exchange constraint corresponding to the target user, transmit the traffic data to a server in compliance with the data exchange constraint, where the types of the traffic data include at least one of: a native type of traffic data associated with a native application, a WebView type of traffic data associated with an application built-in application, and a third-party software development kit, SDK, type of traffic data associated with third- party SDK, where analyzing the traffic data at different layers of the transmission includes in accordance with a determination that the traffic data is of a native type, analyzing the traffic data at a network layer, where analyzing the traffic data at different layers of the transmission includes in accordance with a determination that the traffic data is of a WebView type, transferring the WebView type of traffic data to a network interface of the client application in order to be managed by a native network module of the client application, and analyzing the transferred traffic data at a network layer, where analyzing the traffic data at different layers of the transmission includes in accordance with a determination that the traffic data is of a third-party SDK type, analyzing the traffic data at an application program interface, API, layer, further including a recommendation reviewing sub-system configured to obtain a set of object features associated with a set of objects in the target application, where the set of object features are converted from attributes of the set of objects, which do not directly characterize the attributes of the set of objects, determine a first object feature and a second object feature from the set of object features, a first difference between the first object feature and the second object feature being less than a first threshold, determine, based on a recommendation policy in the target application, a first recommendation result corresponding to the first object feature and a second recommendation result corresponding to the second object feature, and evaluate the recommendation policy based on the first recommendation result and the second recommendation result, where the recommendation reviewing sub-system is further configured to obtain the set of object features via an application program interface, API, provided by the target application.
As recited in dependent Claims 6-17 when also incorporating all of the limitations of their base independent claim, any intervening dependent claims, any additional limitations found in dependent Claims 6-17.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Kim et al - US_10482237_B2_I: Kim et al teaches upon receiving an installation request or an execution request of an application, generating a policy file.
Hopkins et al - US_20150373004_A1_I: Hopkins et al teaches per-partition configuration of security services including configuration for authentication, authorization, credential mapping, auditing, password validation, certificate validation, and user lockout in a multi-tenant server environment.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to BRADLEY HOLDER whose telephone number is 571-270-3789. The examiner can normally be reached on Monday-Friday 10:00AM-7:00PM Eastern Time.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Linglan Edwards, can be reached on (571) 270-5440. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/BRADLEY W HOLDER/
Primary Examiner, Art Unit 2408