DETAILED ACTION
Examiner's Note: The Examiner has pointed out particular references contained in the prior art of record within the body of this action 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. Applicant, in preparing the response, should consider fully the entire reference 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.
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Response to Arguments
Applicant’s remarks filed on 12/05/2025 have been fully considered.
Regarding claim[s] 1 – 27 under the various obviousness rejections, applicant’s remarks are not persuasive, therefore, see the examiner’s response to such remarks in the office action below.
Regarding claim[s] 1 – 27 under the various types of double patenting rejections, applicant’s remarks have been considered, therefore, all rejections are maintained at this time.
The examiner will address all other remarks that do not concern the prior art rejections, if any, in the office action below.
Applicant states on page[s] 10 and 11 of the remarks as filed: “
IV. Double Patenting Rejection
Claims 1-8, 10, 12, 14, and 16 are rejected under obviousness-type double patenting as being unpatentable over claims 1, 3-10, 13, 14, and 16 of U.S. Patent No. 12,056,243 (the "243 Patent"). Claims 1-8, 10, 12, 14-16, 19, and 23 are rejected under obviousness-type double patenting as being unpatentable over claims 1, 3-10, 14-16, 18, and 20 of U.S. Patent No. 11,238,147 (the 147 Patent"). Claims 1-8, 10, 11, 13-17, 19, 20, and 22-26 are rejected under obviousness-type double patenting as being unpatentable over claims 1, 3-9, 11-16, and 18-22 of U.S. Patent No. 11,727,101 (the 101 Patent"). Without admitting to the propriety of the rejections and pursuant to 37 C.F.R. § 1.321(c), the present rejection can be overcome by filing a Terminal Disclaimer with respect to the '243 Patent, the '147 Patent, and the '101 Patent. A terminal disclaimer with respect to the '243 Patent, the '147 Patent, and the '101 Patent has been submitted herewith. Accordingly, Applicant respectfully submits the rejections for non-statutory double patenting are overcome and requests that all pending claims be allowed. Claims 1, 5, 6, 10, 19, 23, and 24 are provisionally rejection on the grounds of non- statutory double patenting as being unpatentable over claims 1, 6, 7, 18, 21, 26, and 27 of U.S. Patent Application No. 18/214,739. Claims 1, 6, 10, 15, and 19 are provisionally rejection on the grounds of non-statutory double patenting as being unpatentable over claims 1, 3, 7, 9, and 13 of U.S. Patent Application No. 19/231,141. Applicant respectfully requests that the provisional rejections under non-statutory double patenting be held in abeyance until a patent actually issues.”
In response the examiner points out that the rejection is maintained until applicant substantially changes the claim language in scope or timely filing of an e-terminal disclaimer to obviate the rejection.
Applicant states on page[s] 11 and 12 of the remarks as filed: “
V. Rejection of Claims Under 35 U.S.C. § 103
Claims 1, 6, 8, 9, 10, 15, 17, and 18 are rejected under 35 U.S.C. § 103 as being unpatentable over U.S. Patent No. 9,684,501 to Falkenburg, et al. ("Falkenburg"), in view of U.S. Patent No. 7,530,065 to Ciudad, et al. ("Ciudad"). Claims 2, 7, 11, and 16 are rejected under 35 U.S.C. § 103 as being unpatentable over Falkenburg in view of Ciudad and further in view of U.S. Patent Publication No. 2014/0026228 to Isozaki et al. ("Isozaki"). Claims 3 and 12 are rejected under 35 U.S.C. § 103 as being unpatentable over Falkenburg in view of Ciudad and further in view of U.S. Patent No. 8,868,915 to Counterman ("Counterman"). Claims 4, 5, 13, and 14 are rejected under 35 U.S.C. § 103 as being unpatentable over Falkenburg in view of Ciudad and further in view of U.S. Patent Publication No. 2017/0302645 to Ducker et al. ("Ducker"). The rejection of the claims is traversed for at least the following reasons. Applicant submits that, for a prima facie case of obviousness, the Examiner is required to "explain why the differences between the prior art and the claimed invention would have been obvious to one of ordinary skill in the art," (MPEP 2141(III)) and provide "articulated reasoning with some rational underpinning to support the legal conclusion of obviousness" (KSR International Co. V. Teleflex Inc., 550 U.S. 398, 82 USPQ2d 1385, 1396 (2007)). MPEP § 2142.02 provides that "[i]n determining the differences between the prior art and the claims, the question under 35 U.S.C. 103 is not whether the differences themselves would have been obvious, but whether the claimed invention as a whole would have been obvious." Id. (citing Stratoflex, Inc. V. Aeroquip Corp., 713 F.2d 1530 (Fed. Cir. 1983)). Furthermore, rejections based on obviousness grounds cannot be sustained by mere conclusory statements; instead, there must be explicit analysis including some rational underpinning to support the legal conclusion of obviousness. K.S.R. International Co. V. Teleflex, Inc., et al., 550 U.S. 14 (2007), citing In re Kahn, 441 F.3d 977, 988 (Fed. Cir. 2006).”
In response the examiner isn’t persuaded, the examiner points to Falkenburg. Specifically, at col. 1, lines 23 - 29, The embodiments described herein provide ways to associate a link, such as a URL, between two applications. In one embodiment, the association is created in a secure way such that a website (e.g., a domain) can control which apps are associated with the website and which portions of the website are permitted to be associated with one or more apps. The examiner points out regarding the citation of Falkenburg above, the operation of Falkenburg is preventing any other application[s] [duplicate applications] or downloaded applications from accessing a website in an unauthorized manner, by securely controlling the relationship between applications thru the use of a URL that is specifically used to access such website. Ciudad has an operation of authenticating the applications already installed on the computer before any operation is executed. Thus, Ciudad enhances the operation of Falkenburg by prevention of installing apps or applications that could compromise the user’s computer and the websites to which the applications already installed on the user’s computer from accessing unsuspecting websites.
Applicant states on page[s] 12 of the remarks as filed: “
A. Claim 1
i. The cited references do not teach "determine, based on a request from a user device for verification of an installed first application of the user device, a second application of the user device"
Independent claim 1 recites, in part, "determine, based on a request from a user device for verification of an installed first application of the user device, a second application of the user device." Independent claim 10 recites similar, but not identical, features. The Patent Office asserts that Falkenburg teaches this element of claim 1. Office Action, pp. 15-16. In support, the Patent Office directs Applicant's attention to column 1, lines 31-42 of Falkenburg. Id. Applicant respectfully traverses the rejection of this element of claim 1. Falkenburg teaches receiving a request to install a first application. Falkenburg, col. 1:31-32. In response to the request, Falkenburg teaches that a client device may download and install the first application and a list specifying one or more URLs or URIs. Id. at col. 1:32-38. Falkenburg teaches that the list or URLs and URIs are stored in a data structure of the client device. Id. at col. 7:4-11. Falkenburg teaches that when a user selects a URL or URI in a second application (e.g., web browser) of the client device, the launch services of the client device compares the selected URL/URI to the URLs and URIs downloaded and stored in the data structure of the client device. Id. at col. 1:38-42; 7:45-58; and 8:10-15. Falkenburg further teaches that if the selected URL/URI at the client device matches the stored URL/URI in the client device, the client device may launch the URL in the downloaded first application of the client device. Id. at col. 1:43-53. Thus, Falkenburg teaches a client device determining if a selected link in a second application of the client device is included in a stored list of URLs/URIs of the client device in order to determine if the link should be launched in the first application or the second application. However, Falkenburg fails to teach or suggest an apparatus that "determine[s], based on a request from a user device for verification of an installed first application of a user device, a second application of the user device," as recited in claim 1. Applicant further submits that Ciudad, Das, Counterman, Isozaki, and Ducker fail to cure the deficiencies of Falkenburg.”
In response the examiner isn't persuaded, the examiner points to the prior art of Falkenburg. Specifically, at col. 1, lines 31 - 42, receiving a request to install a first application at a server [i.e. applicant's a computing device]; downloading the first application to a device [i.e. applicant's user device] and downloading a list associated with the first application, the list specifying one or more URLs (Uniform Resource Locator) or URIs (Uniform Resource Identifier) in at least one domain specified in the list; installing the first application and downloading a signed list of one or more URLs or URIs; validating the signed list of URLs or URIs; storing, in a data structure, an association between the URLs or URIs in the signed list and the first application; receiving a selection of a URL or URI in a second application.
**The examiner’s response above applies equally to the same or similar remarks made on page[s] 13 regarding base claim 10 of the remarks as filed.
Applicant states on page[s] 13 and 14 of the remarks as filed: “
ii. The cited references do not teach "send, to the second application, notification that causes the second application to determine information associated with the first application" Independent claim 1 recites, in part, "send, to the second application, a notification that causes the second application to determine information associated with the first application." Independent claim 10 recites similar, but not identical, features. The Patent Office asserts that Falkenburg teaches this element of claim 1. Office Action, p. 16. In support, the Patent Office directs Applicant's attention to column 1, line 64 to column 2, line 7 of Falkenburg. Id. Applicant respectfully traverses the rejection of this element of claim 1. As discussed above, Falkenburg teaches receiving a request to install a first application. Falkenburg, col. 1:31-32. In response to the request, Falkenburg teaches that a client device may download and install the first application and a list specifying one or more URLs or URIs. Id. at col. 1:32-38. Falkenburg teaches that the list or URLs and URIs are stored in a data structure of the client device. Id. at col. 7:4-11. Falkenburg teaches that first application is downloaded from the app store and the second application is a web browser on the client device. Id. at col. 1:64- 2:3. Falkenburg teaches that when a user selects a URL or URI in a second application (e.g., web browser) of the client device, the launch services of the client device compares the selected URL/URI to the URLs and URIs downloaded and stored in the data structure of the client device. Id. at col. 1:38-42; 7:45-58; and 8:10-15. Falkenburg further teaches that if the selected URL/URI at the client device matches the stored URL/URI in the client device, the client device may launch the URL in the downloaded first application of the client device. Id. at col. 1:43-53. Falkenburg further teaches that even if the selected URL/URI matches the stored URL/URI in the client device, the URL may be launched in the second application (web browser) at the client device. Id. at col. 2:3-10. Thus, Falkenburg teaches an application may be downloaded from an app store. Falkenburg further teaches a client device determining if a selected link in a second application of the client device is included in a stored list of URLs/URIs of the client device in order to determine if the link should be launched in the first application or the second application. However, Falkenburg fails to teach or suggest an apparatus that "send[s], to the second application, a notification that causes the second application to determine information associated with the first application," as recited in claim 1. Applicant further submits that Ciudad, Das, Counterman, Isozaki, and Ducker fail to cure the deficiencies of Falkenburg.”
In response the examiner isn't persuaded, the examiner points to Falkenburg. Specifically of Falkenberg, at col. 1, lines 64 - 67 and col. 2, lines 1 - 7, In one embodiment, the first application is distributed through an app store and is downloaded from the app store of server [i.e. applicant's by the computing device]. In one embodiment, the domain controls the paths in the domain that are associated with the first application by limiting the URLs or URIs in the signed list of URLs or URIs. In one embodiment, the second application is a web browser and the content of the selected application is displayed in the second application [i.e. applicant's second application to determine information associated with the first application], rather than the first application, if the selected URL or URI is in the domain.
Where further of Falkenburg at col. 1, lines 47 - 53, In one embodiment, the signed list of one or more URLs or URIs is downloaded [i.e. applicant's notification] from a server in the domain specified in the list, and the signed list is a cryptographically signed data structure which authenticates the list of URLs or URIs (in the signed list) as being authentic and authorized by the domain of the website.
**The examiner’s response above applies equally to the same or similar remarks made on page[s] 14 regarding base claim 10 of the remarks as filed.
Applicant states on page[s] 14 and 15 of the remarks as filed: “
iii. The cited references do not teach "send, to the user device and based on the information associated with the first application, an indication that the first application is the verified application"
Independent claim 1 recites, in part, "send, to the user device and based on the information associated with the first application, an indication that the first application is the verified application." Independent claim 10 recites similar, but not identical, features. The Patent Office asserts that Ciudad teaches this element of claim 1. Office Action, p. 17. In support, the Patent Office directs Applicant's attention to column 5, lines 45-58 of Ciudad. Id. Applicant respectfully traverses the rejection of this element of claim 1.
Ciudad is generally directed to determining if a software patch is applicable for installing on a client device. Ciudad, Abstract. Ciudad teaches that when a client device requires an upgrade it downloads an installer and PKM file that corresponds to the software package being installed. Id. at col. 5:45-47. The installer on the client device retrieves an installation description from the PKM file to determine an installation configuration for the software being installed. Id. at col. 5:51-54. The installation description may include versioning and authentication information that are used by the client device to "verify one or more existing components and/or files 105 that have already been installed in the client from which the new patches or components may be installed." Id. at col. 5:54-58. Thus, Ciudad teaches an installer is installed on a client device. Ciudad further teaches the installer retrieves information to verify the configuration of components or files of a software application prior to applying a patch. Thus, Ciudad teaches that the client device verifying the configuration of components. However, Ciudad fails to teach or suggest "send, to the user device and based on the information associated with the first application, an indication that the first application is the verified application." As the client device of Ciudad is doing the verification itself, no indication of verification would be sent to that client device of Ciudad. Applicant further submits that Falkenburg, Das, Counterman, Isozaki, and Ducker fail to cure the deficiencies of Ciudad.”
In response the examiner isn't persuaded, the examiner points to Falkenburg. Specifically of Falkenberg, at col. 1, lines 64 - 67 and col. 2, lines 1 - 7, In one embodiment, the first application is distributed through an app store and is downloaded from the app store of server [i.e. applicants by the computing device]. In one embodiment, the domain controls the paths in the domain that are associated with the first application by limiting the URLs or URIs in the signed list of URLs or URIs. In one embodiment, the second application is a web browser and the content of the selected application is displayed in the second application [i.e. applicant's second application to determine information associated with the first application], rather than the first application, if the selected URL or URI is in the domain.
Where further of Falkenburg at col. 1, lines 47 - 53, In one embodiment, the signed list of one or more URLs or URIs is downloaded [i.e. applicant's notification] from a server in the domain specified in the list, and the signed list is a cryptographically signed data structure which authenticates the list of URLs or URIs (in the signed list) as being authentic and authorized by the domain of the website.
**The examiner’s response above applies equally to the same or similar remarks made on page[s] 15 regarding base claim 10 of the remarks as filed.
Applicant states on page[s] 15 and 16 of the remarks as filed: “
B. The motivation to combine Falkenburg and Ciudad is not supported
Applicant respectfully submits that the motivation to combine Falkenburg and Ciudad is not supported. The Supreme Court of the United States noted that the analysis supporting a rejection under 35 U.S.C. §103 should be made explicit. See KSR International Co. V. Teleflex Inc. (KSR), 550 U.S. 398, 82 USPQ2d 1385 (2007). The Court quoting In re Kahn, 441 F.3d 977, 988, 78 USPQ2d 1329, 1336 (Fed. Cir. 2006), stated that "rejections on obviousness cannot be sustained by mere conclusory statements; instead, there must be some articulated reasoning with some rational underpinning to support the legal conclusion of obviousness." KSR, 550 U.S. at 398, 82 USPQ2d at 1396. The claimed invention as a whole must be compared to the prior art references. Claim limitations are not puzzle pieces to be matched to atomized prior art reference suggestions, and thus examined out of context. Only if the prior art aligns with the claimed invention in principles of operation may a combination of prior art references render a claim obvious. Although factual findings made by Office personnel are the necessary underpinnings to establish obviousness, once the findings of fact are articulated, Office personnel must provide an explanation to support an obviousness rejection under 35 U.S.C. § 103. 35 U.S.C. § 132 requires that the Applicant be notified of the reasons for the rejection of the claim so that he or she can decide how best to proceed. Clearly setting forth findings of fact and the rationale(s) to support a rejection in an Office Action is required. The key to supporting any rejection under 35 U.S.C. § 103 is the clear articulation of the reason(s) why the claimed invention would have been obvious. As noted above, the Supreme Court in KSR noted that the analysis supporting a rejection under 35 U.S.C. § 103 should be made explicit. The Patent Office fails to provide a proper motivation to combine with reference to claims 1 and 10. With regard to claims 1 and 10, the Patent Office simply concludes it would have been obvious to one of ordinary skill in the art "to combine the teachings of Falkenburg device of Falkenburg to include an authentication operation of the and Ciudad in order for the installed components of the device of Ciudad' Office Action, pp. 17-18. The Patent Office goes on to state, that "[t]his would allow for preventing duplicate component installations." Id. However, Falkenburg does not suffer the problem of duplicate component installations as alleged by the Patent Office. As such, Applicant traverses this alleged motivation to combine.”
In response the examiner isn’t persuaded, the examiner points to Falkenburg. Specifically, at col. 1, lines 23 - 29, The embodiments described herein provide ways to associate a link, such as a URL, between two applications. In one embodiment, the association is created in a secure way such that a website (e.g., a domain) can control which apps are associated with the website and which portions of the website are permitted to be associated with one or more apps. The examiner points out regarding the citation of Falkenburg above, the operation of Falkenburg is preventing any other application[s] [duplicate applications] or downloaded applications from accessing a website in an unauthorized manner, by securely controlling the relationship between applications thru the use of a URL that is specifically used to access such website. Ciudad has an operation of authenticating the applications already installed on the computer before any operation is executed. Thus, Ciudad enhances the operation of Falkenburg by prevention of installing apps or applications that could compromise the user’s computer and the websites to which the applications already installed on the user’s computer from accessing unsuspecting websites.
Applicant states on page[s] 16 and 17 of the remarks as filed: “Applicant submits the Patent Office is creating a problem in the primary reference, Falkenburg, in order to solve the problem with the secondary reference, Ciudad, that did not exist in the primary reference, but for the Patent Office wanting to modify the primary reference with the secondary reference in order to reject the claim. Falkenburg is directed to verifying that a website or linked content can be loaded on an app separate from the web browser, from which the website or linked content is selected, by comparing a selected link at the web browser to a stored listing of website-to-app mappings. Falkenburg, col. 7:59-8:67. Falkenburg has no need for verifying the installed files of the app as taught by Ciudad because Falkenburg is not modifying or updating any part of the app for which the website or linked content may be displayed. Further Falkenburg has no problem associated with duplicate component installations, as described in Ciudad and the Office Action. Unlike Ciudad, which is modifying the software with or more patches, which creates a problem with regard to which components and versions of components or patches may have already been installed for this software, Falkenburg does not teach modifying the app in any manner. Falkenburg simply teaches comparing the URL/URI associated with the selected link in the web browser to a stored list of websites that can be displayed on the app. Since the app is not modified, one of ordinary skill in the art would not be motivated to combine the teachings of software version verification in Ciudad with the teachings of Falkenburg.”
In response the examiner isn’t persuaded, the examiner points to Falkenburg. Specifically, at col. 1, lines 23 - 29, The embodiments described herein provide ways to associate a link, such as a URL, between two applications. In one embodiment, the association is created in a secure way such that a website (e.g., a domain) can control which apps are associated with the website and which portions of the website are permitted to be associated with one or more apps. The examiner points out regarding the citation of Falkenburg above, the operation of Falkenburg is preventing any other application[s] [duplicate applications] or downloaded applications from accessing a website in an unauthorized manner, by securely controlling the relationship between applications thru the use of a URL that is specifically used to access such website. Ciudad has an operation of authenticating the applications already installed on the computer before any operation is executed. Thus, Ciudad enhances the operation of Falkenburg by prevention of installing apps or applications that could compromise the user’s computer and the websites to which the applications already installed on the user’s computer from accessing unsuspecting websites.
**The examiner’s response above applies equally to the same or similar remarks made on page[s] 17 of the remarks as filed.
Response to Amendment
Status of the instant application:
Claim[s] 1 – 27 are pending in the instant application.
Regarding claim[s] 1 – 27 under the various obviousness rejections, applicant made NO claim amendments, therefore, the rejections are maintained at this time.
Specification
Applicant’s amendment to the abstract filed on 12/05/2025 has been considered, therefore, the objection is withdrawn.
Double Patenting
The non-statutory 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 non-statutory 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 non-statutory 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 non-statutory 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 e-Terminal Disclaimer may be filled out completely online using web-screens. An e-Terminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about e-Terminal Disclaimers, refer to www.uspto.gov/patents/apply/applying-online/eterminal-disclaimer.
Claim[s] 1 – 8, 10, 12, 14, 16 are rejected on the ground of non-statutory double patenting as being unpatentable over claim[s] 1, 3 – 10, 13, 14, 16 of U.S. Patent No. 12056243. Although the claims at issue are not identical, they are not patentably distinct from each other because the subject matter of the pending application and the reference patent claim the same or similar subject matter and are in NOT distinct in any manner:
“determining an installed first application by a second application based on a received request, forwarding a notification to a second application where the second application determines information associated with the first application. Then receiving from the second application the information associated with the first application, that then forwards an indication of the verification of whether the first application is verified.”
Also, see the table below for a claim-by-claim comparison.
Pending US Application # 18/752053
US PAT # 12056243
1
1
2
3
3
4
4
5
5
6
6
7
7
8
8
9
10
10
12
13
14
14
16
16
Claim[s] 1 – 8, 10, 12, 14 – 16, 19, 23 are rejected on the ground of non-statutory double patenting as being unpatentable over claim[s] 1, 3 – 10, 14 – 16, 18, 20 of U.S. Patent No. 11238147.
Although the claims at issue are not identical, they are not patentably distinct from each other because the subject matter of the pending application and the reference patent claim the same or similar subject matter and are in NOT distinct in any manner:
“determining an installed first application by a second application based on a received request, forwarding a notification to a second application where the second application determines information associated with the first application. Then receiving from the second application the information associated with the first application, that then forwards an indication of the verification of whether the first application is verified.”
Also, see the table below for a claim-by-claim comparison.
Pending US Application # 18/752053
US PAT# 11238147
1
1
2
3
3
4
4
5
5
6
6
7
7
8
8
9
10
10
12
13
14
14
15
15
16
16
19
18
23
20
Claim[s] 1 – 8, 10, 11, 13 – 17, 19, 20, 22 – 26 are rejected on the ground of non-statutory double patenting as being unpatentable over claim[s] 1, 3 – 9, 11 – 16, 18 - 22 of U.S. Patent No. 11727101.
Although the claims at issue are not identical, they are not patentably distinct from each other because the subject matter of the pending application and the reference patent claim the same or similar subject matter and are in NOT distinct in any manner:
“determining an installed first application by a second application based on a received request, forwarding a notification to a second application where the second application determines information associated with the first application. Then receiving from the second application the information associated with the first application, that then forwards an indication of the verification of whether the first application is verified.”
Also, see the table below for a claim-by-claim comparison.
Pending US App. # 18/752053
US PAT # 11727101
1
1
2
3
3
4
4
5
5
6
6
6
7
7
8
8
10
9
11
11
13
12
14
13
15
13
16
14
17
15
19
16
20
18
22
19
23
20
24
20
25
21
26
22
Double Patenting
The non-statutory 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 non-statutory 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 non-statutory 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 non-statutory 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 e-Terminal Disclaimer may be filled out completely online using web-screens. An e-Terminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about e-Terminal Disclaimers, refer to www.uspto.gov/patents/apply/applying-online/eterminal-disclaimer.
Claim[s] 1, 5, 6, 10, 19, 23, 24 are provisionally rejected on the ground of non-statutory double patenting as being unpatentable over claim[s] 1, 6, 7, 18, 21, 26, 27 of co-pending Application No. 18/214739 (reference application).
Although the claims at issue are not identical, they are not patentably distinct from each other because the subject matter of the pending application and the reference co-pending application claim the same or similar subject matter and are in NOT distinct in any manner:
“determining an installed first application by a second application based on a received request, forwarding a notification to a second application where the second application determines information associated with the first application. Then receiving from the second application the information associated with the first application, that then forwards an indication of the verification of whether the first application is verified.”
This is a provisional non-statutory double patenting rejection because the patentably indistinct claims have not in fact been patented.
Also, see the table below for a claim-by-claim comparison.
Pending US Application # 18/752053
Co-pending US Application # 18/214739
1
1
5
6
6
7
10
18
19
21
23
26
24
27
Claim[s] 1, 6, 10, 15, 19 are provisionally rejected on the ground of non-statutory double patenting as being unpatentable over claim[s] 1, 3, 7, 9, 13 of co-pending Application No. 19/231141(reference application).
Although the claims at issue are not identical, they are not patentably distinct from each other because the subject matter of the pending application and the reference co-pending application claim the same or similar subject matter and are in NOT distinct in any manner:
“determining an installed first application by a second application based on a received request, forwarding a notification to a second application where the second application determines information associated with the first application. Then receiving from the second application the information associated with the first application, that then forwards an indication of the verification of whether the first application is verified.”
This is a provisional non-statutory double patenting rejection because the patentably indistinct claims have not in fact been patented.
Also, see the table below for a claim-by-claim comparison.
Pending Application # 18/752053
Co-pending US Application # 19/231141
1
1
6
3
10
7
15
9
19
13
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.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or non-obviousness.
Claim(s) 1, 6, 8, 9, 10, 15, 17, 18 is/are rejected under 35 U.S.C. 103 as being unpatentable over Falkenburg et al. [US PAT # 9684501] in view of Ciudad et al. [US PAT # 7530065]
As per claim 1. Falkenburg does teach an apparatus [col. 1, lines 23 – 29, The embodiments described herein provide ways to associate a link, such as a URL, between two applications. In one embodiment, the association is created in a secure way such that a website (e.g., a domain) can control which apps are associated with the website and which portions of the website are permitted to be associated with one or more apps.] comprising:
one or more processors [Figure # 9, component 906, and col. 9, lines 64 – 67, and col. 10, lines 1 – 5, one or more microprocessors # 906]; and
memory [Figure # 9, components # 907, 905, 911] storing processor-executable instructions that, when executed by the one or more processors [Figure # 9, col. 10, lines 1 - 23], cause the apparatus to:
determine, based on a request from a user device for verification of an installed first application of the user device, a second application of the user device [col. 1, lines 31 – 42, receiving a request to install a first application; downloading the first application to a device and downloading a list associated with the first application, the list specifying one or more URLs (Uniform Resource Locator) or URIs (Uniform Resource Identifier) in at least one domain specified in the list; installing the first application and downloading a signed list of one or more URLs or URIs; validating the signed list of URLs or URIs; storing, in a data structure, an association between the URLs or URIs in the signed list and the first application; receiving a selection of a URL or URI in a second application];
send, to the second application, a notification that causes the second application to determine information associated with the first application [col. 1, lines 64 – 67 and col. 2, lines 1 – 7, In one embodiment, the first application is distributed through an app store and is downloaded from the app store. In one embodiment, the domain controls the paths in the domain that are associated with the first application by limiting the URLs or URIs in the signed list of URLs or URIs. In one embodiment, the second application is a web browser and the content of the selected application is displayed in the second application [i.e. applicant’s second application to determine information associated with the first application], rather than the first application, if the selected URL or URI is in the domain. Where at col. 1, lines 47 – 53, In one embodiment, the signed list of one or more URLs or URIs is downloaded [i.e. applicant’s notification] from a server in the domain specified in the list, and the signed list is a cryptographically signed data structure which authenticates the list of URLs or URIs (in the signed list) as being authentic and authorized by the domain of the website.];
receive, from the second application, the information associated with the first application [col. 2, lines 7 – 10, In one embodiment, a user selectable preference setting may be provided through a user interface that allows a user to disable displaying, in the first application, content from a URL or URI selected in the second application.].
Faulkenburg does not clearly teach the claim limitation of: “and
send, to the user device and based on the information associated with the first application, an indication that the first application is a verified application.”
However, Ciudad does teach the claim limitation of: “and
send, to the user device and based on the information associated with the first application, an indication that the first application is a verified application [col. 5, lines 45 – 58, When client system 101 requires an upgrade, the client 101 may download the installer 104 and the PKM file 106 corresponding to the software package being installed. Alternatively, the client system 101 includes the installer 104 pre-installed when the client system was manufactured. In which case, the client 101 only needs to download the PKM file 106. In one embodiment, the installer 104 retrieves installation description from the PKM file 106 to determine the installation configuration of the respective software package being installed. The installation description may include versioning and authentication information, which may be used to verify one or more existing components and/or files 105 that have already been installed in the client 101 from which the new patches or components may be installed.].”
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 Falkenburg and Ciudad in order for the downloading and determining of a first application is able to display or show content from a trusted URL or URI list of a content server on a device of Falkenburg to include an authentication operation of the installed components of the device of Ciudad. This would allow for preventing duplicate component installations. See col. 13, lines 19 – 22 of Ciudad.
As per claim 6. Falkenburg does teach the apparatus of claim 1, wherein the information associated with the first application comprises one or more of a valid installation signature [Falkenburg, col. 3, lines 63 – 67, and col. 4, lines 1 – 3, When the user selects a URL or URI in the first app (in for example a web page or an email or a tweet), the system checks the selected URL or URI against a validated list of URLs or URIs, wherein each URL or URI in the validated list is associated with a receiving or second app that has been, in effect, approved for use (in the installation process) by that website (or owner of the URL in that domain)], an installation date, an installation time, or an application package identifier.
As per claim 8. Falkenburg as modified does teach the apparatus of claim 1, wherein the request comprises an identifier of the user device and wherein the information associated with the first application indicates that the first application is installed on one or more of the user device [Ciudad, col. 5, lines 51 – 58, When client system 101 requires an upgrade, the client 101 may download the installer 104 and the PKM file 106 corresponding to the software package being installed. Alternatively, the client system 101 includes the installer 104 pre-installed when the client system was manufactured. In which case, the client 101 only needs to download the PKM file 106. In one embodiment, the installer 104 retrieves installation description from the PKM file 106 to determine the installation configuration of the respective software package being installed. The installation description may include versioning and authentication information, which may be used to verify one or more existing components and/or files 105 that have already been installed in the client 101 from which the new patches or components may be installed.] or another user device associated with the user device.
As per claim 9. Falkenburg as modified does teach the apparatus of claim 1, wherein the processor-executable instructions, when executed by the one or more processors, further cause the apparatus to determine, based on the information, the first application is the verified application, wherein the processor-executable instructions that, when executed by the one or more processors, cause the apparatus to send, based on the information associated with the first application, the indication that the first application is the verified application [Ciudad, col. 5, lines 45 – 58, When client system 101 requires an upgrade, the client 101 may download the installer 104 and the PKM file 106 corresponding to the software package being installed. Alternatively, the client system 101 includes the installer 104 pre-installed when the client system was manufactured. In which case, the client 101 only needs to download the PKM file 106. In one embodiment, the installer 104 retrieves installation description from the PKM file 106 to determine the installation configuration of the respective software package being installed. The installation description may include versioning and authentication information, which may be used to verify one or more existing components and/or files 105 that have already been installed in the client 101 from which the new patches or components may be installed], cause the apparatus to send the indication based on determining the first application is the verified application [Ciudad, col. 5, lines 45 – 58].
As per non – transitory computer-readable media claim 10, that includes the same or similar claim limitations as apparatus claim 1, and is similarly rejected.
***The examiner notes that the recited: “one or more non – transitory computer – readable media,” “storing processor executable instructions,” and “at least one processor,” is taught by the prior art of Falkenburg at Figure # 9, col. 9, lines 64 – 67, and col. 10, lines 1 – 23.
As per non – transitory computer-readable media claim 15, that includes the same or similar claim limitations as apparatus claim 6, and is similarly rejected.
As per non – transitory computer-readable media claim 17, that includes the same or similar claim limitations as apparatus claim 8, and is similarly rejected.
As per non – transitory computer-readable media claim 18, that includes the same or similar claim limitations as apparatus claim 9, and is similarly rejected.
Claim(s) 2, 7, 11, 16 is/are rejected under 35 U.S.C. 103 as being unpatentable over Falkenburg et al. [US PAT # 9684501] in view of Ciudad et al. [US PAT # 7530065] as applied to claim[s] 1 above, and further in view of Isozaki et al. [US PGPUB # 2014/0026228]
As per claim 2. Falkenburg and Ciudad do teach what is taught in the rejection of claim # 1 above.
Falkenburg and Ciudad do not clearly teach the apparatus of claim 1, wherein the request for verification comprises an instance identifier (IID) associated with the first application and wherein the processor-executable instructions, when executed by the one or more processors, further cause the apparatus to:
determine, based on the IID, that the first application is not associated with a whitelist; and
cause, based on determining that the first application is not associated with the whitelist, one or more of uninstallation or deactivation of the first application.
However, Isozaki does teach the apparatus of claim 1, wherein the request for verification comprises an instance identifier (IID) associated with the first application and wherein the processor-executable instructions, when executed by the one or more processors, further cause the apparatus to:
determine, based on the IID, that the first application is not associated with a whitelist [paragraph: 0067, lines 3 – 10, Based on a rule set (determination rule) which is present in the determination rule management module 113, the event determination module 112 determines permission or prohibition of install of an application program corresponding to the application name included in the install event information. The rule set (determination rule) may be, for example, a list (white list) of application names, the install of which is to be permitted]; and
cause, based on determining that the first application is not associated with the whitelist, one or more of uninstallation or deactivation of the first application [paragraph: 0067, lines 10 – 13, a list (black list) of application names, the install of which is to be prohibited, or a list of application names, the uninstall of which is to be permitted (or a list of application names, the uninstall of which is to be prohibited)].
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 Falkenburg as modified and Isozaki in order for the downloading and determining of a first application is able to display or show content from a trusted URL or URI list of a content server on a device of Falkenburg as modified to include using a permission level of Isozak, this would allow for the prevention of downloading an application that is a falsified application by assessing the permission level of the user downloading the application. See paragraph: 0005 of Isozaki.
As per claim 7. Falkenburg as modified does teach the apparatus of claim 1, wherein the processor-executable instructions that, when executed by the one or more processors, cause the apparatus to receive the information associated with the first application, cause the apparatus to receive information associated with the second application, wherein the information associated with the second application comprises an instance identifier (ID) associated with the second application [Isozaki, paragraph: 0063, lines 1 – 11, The management application identification module 104 [i.e. applicant’s first application] identifies which of applications on the application execution module 20 is the management application module 21 [i.e. applicant’s second application]. After detected by the event detection module 102, the event information (install event information) is transmitted, via the management application event communication module 103, to the application which has been identified as the management application module 21 by the management application identification module 104. Specifically, the management application identification module 104 pre-stores the application name [i.e. applicant’s an instance identifier (IID) associated with the second application] of the management application module 21].
As per non – transitory computer-readable media claim 11, that includes the same or similar claim limitations as apparatus claim 2, and is similarly rejected.
As per non – transitory computer-readable media claim 16, that includes the same or similar claim limitations as apparatus claim 7, and is similarly rejected.
Claim(s) 3, 12 is/are rejected under 35 U.S.C. 103 as being unpatentable over Falkenburg et al. [US PAT # 9684501] in view of Ciudad et al. [US PAT # 7530065] as applied to claim[s] 1 above, and further in view of Counterman et al. [US PAT # 8868915]
As per claim 3. Falkenburg and Ciudad do teach what is taught in the rejection of claim # 1 above.
Falkenburg and Ciudad do not clearly teach the apparatus of claim 1, wherein the request comprises an identifier of the user device and wherein the identifier of the user device comprises one or more of a mobile directory number (MDN), a mobile identification number (MIN), an international mobile subscriber identity MSD, or an international mobile equipment identifier (MEI).
However, Counterman does teach the apparatus of claim 1, wherein the request comprises an identifier of the user device and wherein the identifier of the user device comprises one or more of a mobile directory number (MDN), a mobile identification number (MIN), an international mobile subscriber identity MSD [Col. 2, lines 10 – 13, IMSI], or an international mobile equipment identifier (MEI) [[Col. 2, lines 10 – 13, IMEI]].
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 Falkenburg as modified and Counterman in order for the downloading and determining of whether a first application is able to display or show content from a trusted URL or URI list of a content server on a device of Falkenburg as modified to include the use of authentication replication data operation of Counterman. This would allow for the device and server to determine the authenticity of the downloaded first application, and that the application is not a replicated application, moreover, by authenticating the application based on the application’s previously used identifier, and the device identifier that the previous application was resident on. See col. 1, lines 49 – 67 and col. 2, lines 1 – 5 of Counterman.
As per non – transitory computer-readable media claim 12, that includes the same or similar claim limitations as apparatus claim 3, and is similarly rejected.
Claim(s) 4, 5, 13, 14 is/are rejected under 35 U.S.C. 103 as being unpatentable over Falkenburg et al. [US PAT # 9684501] in view of Ciudad et al. [US PAT # 7530065] as applied to claim[s] 1 above, and further in view of Ducker et al. [US PGPUB # 2017/0302645]
As per claim 4. Falkenburg and Ciudad do teach what is taught in the rejection of claim # 1 above.
Falkenburg and Ciudad do not clearly teach the apparatus of claim 1, wherein the second application is another verified application, wherein the processor-executable instructions that, when executed by the one or more processors, cause the apparatus to determine the second application, cause the apparatus to:
determine one or more of a user profile or a user account; and
determine, based on the one or more of the user profile or the user account, the second application.
However, Ducker does teach the apparatus of claim 1, wherein the second application is another verified application, wherein the processor-executable instructions that, when executed by the one or more processors, cause the apparatus to determine the second application, cause the apparatus to:
determine one or more of a user profile or a user account [paragraph: 0005, lines 2 – 23, an identity module executing on the computer processor and configured to enable the computer processor to: receive, from a client device, an authorization request originating from an authorization module of an application executing on the client device, where the authorization request includes an identifier identifying the client device; cause, in response to the authorization request, transmission of a verification message to the client device using the identifier, where the verification message includes a verification code; receive a confirmation of the verification code from the authorization module of the application executing on the client device; authenticate the application based on the receiving the confirmation of the verification code; determine, after authenticating the application, that the client device identified by the identifier corresponds to a user account including secure user data associated with a user; and transmit, to the authorization module of the application, a unique token verifying that the application is authorized to sign into the user account, where: the unique token uniquely identifies the user account to the application, and the secure user data is not shared with the application]; and
determine, based on the one or more of the user profile or the user account, the second application [paragraph: 0005, lines 2 – 23, an identity module executing on the computer processor and configured to enable the computer processor to: receive, from a client device, an authorization request originating from an authorization module of an application executing on the client device, where the authorization request includes an identifier identifying the client device; cause, in response to the authorization request, transmission of a verification message to the client device using the identifier, where the verification message includes a verification code; receive a confirmation of the verification code from the authorization module of the application executing on the client device; authenticate the application [i.e. applicant’s second application] based on the receiving the confirmation of the verification code].
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 Falkenburg as modified and Ducker in order for the downloading and determining of whether a first application is able to display or show content from a trusted URL or URI list of a content server on a device of Falkenburg as modified to include sending challenge response message with verification code to the server storing the first application of Ducker. This would allow for the user of a user device to evaluate the authenticity of the would-be downloaded first application. See paragraph: 0004 of Ducker.
As per claim 5. Falkenburg as modified does teach the apparatus of claim 1, wherein the notification comprises one or more of a push notification, a wireless access protocol (WAP) push message, or an enhanced message service (EMS) message [Ducker, paragraph: 0040, the verification message 504…..and/or any other message form or medium].
As per non – transitory computer-readable media claim 13, that includes the same or similar claim limitations as apparatus claim 4, and is similarly rejected.
As per non – transitory computer-readable media claim 14, that includes the same or similar claim limitations as apparatus claim 5, and is similarly rejected.
Allowable Subject Matter
Claim[s] 19 – 27 contain allowable, but as allowable subject matter has been indicated, applicant's reply must either comply with all formal requirements or specifically traverse each requirement not complied with. See 37 CFR 1.111(b) and MPEP § 707.07(a).
***The examiner notes that a reason’s for allowance can be written once all formal requirements as identified above have been overcome.
Conclusion
THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to DANT SHAIFER - HARRIMAN whose telephone number is (571)272-7910. The examiner can normally be reached M - F: 9am to 5pm.
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, Kambiz Zand can be reached at 571- 272- 3811. 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.
/DANT B SHAIFER HARRIMAN/ Primary Examiner, Art Unit 2434