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 a reply to the application filed on 11/13/2024, in which, claim(s) 1-15 are pending.
Information Disclosure Statement
The information disclosure statement (IDS) submitted on 8/15/2025 and 10/21/2025, has been reviewed. The submission is in compliance with the provisions of 37 CFR 1.97. Accordingly, the examiner is considering the information disclosure statement.
Specification
The lengthy specification has not been checked to the extent necessary to determine the presence of all possible minor errors. Applicant’s cooperation is requested in correcting any errors of which applicant may become aware in the specification.
Drawings
The drawings filed on 11/13/2024 is/are accepted by The Examiner.
Claim Rejections - 35 USC § 102
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 the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
Claim(s) 1-7, 9-10 and 14-15 is/are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Krstic et al. (US 20150347748 A1; hereinafter Krstic).
Regarding claims 1, 14 and 15, Krstic discloses a method, comprising:
at an application of a device (host application on host device communicating with application extension [Krstic; ¶52-62, 70-71; Figs. 2s, 3s, 4, 8s and associated text]):
while the application is active, sending, to a system process, a request for one or more paths previously provided to an extension of the application (a first application wishes to access a predefined functionality (e.g., content sharing or photo filtering) provided by another application, the first application communicates with the corresponding extension point associated with that predefined functionality to inquire about who can provide such a service. The extension framework in turn searches and identifies a list of one or more extensions provided by other applications that have been registered with the extension framework to provide the requested service. The App extension is within an application bundle, the application bundle may be a directory that allows related resources to be grouped together. The executable files in an application may link against the frameworks by storing a framework name or other identifier of framework bundles in a designated location in the application bundle and/or by calling an API provided by the associated framework. The share command transmitted over path may further includes a data object having a reduced resolution image of content. Host application and sharing extension may communicate with each other via an IPC framework provided by sharing extension point [Krstic; ¶Abstract, 35-45, 77-78, 87-95; Figs. 2s, 3s, 4, 8s and associated text]);
after sending the request for one or more paths previously provided to the extension of the application, receiving, from the system process, a first set of one or more paths previously provided to the extension of the application (The extension framework may return the list of the identified extensions to allow the first application to select for the requested service [Krstic; ¶Abstract, 35-45, 87-95; Figs. 2s, 3s, 4, 8s and associated text]); and
after receiving the first set of one or more paths previously provided to the extension of the application, obtaining first content at a first path of the first set of one or more paths (In response to a selection of one of the extensions, the extension framework launches the selected extension in a separate sandboxed environment and facilitates an inter-process communications (IPC) mechanism or framework between the first application and the selected extension to allow the first application to access the functionalities of the selected extension via the IPC communications mechanism, such as sharing extension path (e.g., Twitter, Facebook, AirDrop, etc.,) [Krstic; ¶Abstract, 35-45, 87-97; Figs. 2s, 3s, 4, 8s and associated text]).
Regarding claim 2, Krstic discloses the method of claim 1, wherein the request for one or more paths provided to the extension of the application is a first request, the method further comprising: while the application is active, sending, to the system process, a second request, separate from the first request, for one or more paths previously provided to the extension of the application; and after sending the second request for one or more paths previously provided to the extension of the application, receiving, from the system process, the first set of one or more paths previously provided to the extension of the application (the request is repetitive, continuous request can be made as there are different services [Krstic; ¶Abstract, 35-45, 87-95; Figs. 2s, 3s, 4, 8s and associated text]).
Regarding claim 3, Krstic discloses the method of claim 1, further comprising: while the application is active, sending, to the system process, a third request, separate from the first request, for one or more paths previously provided to the extension of the application; and after sending the third request for one or more paths previously provided to the extension of the application, receiving, from the system process, a second set of one or more paths, different from the first set of one or more paths, previously provided to the extension of the application (the request is repetitive, continuous request can be made as there are different services [Krstic; ¶Abstract, 35-45, 87-95; Figs. 2s, 3s, 4, 8s and associated text]).
Regarding claim 4, Krstic discloses the method of claim 1, further comprising: sending, to the system process, a request to invalidate a second path of the first set of one or more paths; after sending the request to invalidate the second path of the first set of one or more paths, sending, to the system process, a fourth request, separate from the first request, for one or more paths previously provided to the extension of the application; and after sending the fourth request, receiving, from the system process, a third set of one or more paths that does not include the second path (request for terminating connection can be made between application and extension for different reasoning, and new connection to different extension can be made [Krstic; ¶87-98; Figs. 2s, 3s, 4, 8s and associated text]).
Regarding claim 5, Krstic discloses the method of claim 1, further comprising: at the extension of the application: in conjunction with being launched, receiving, from the system process, a third path of the first set of one or more paths (the different path can be made at different phase of the communication [Krstic; ¶87-98; Figs. 8s and associated text]).
Regarding claim 6, Krstic discloses the method of claim 5, wherein the extension of the application is restricted from accessing a location within a container of the application except for the third path in conjunction with receiving the third path (Each extension point is associated with a predefined set of policies (e.g., resource entitlements or restrictions) and specifies what messages can be exchanged between the host application and the extension. All extensions designed for a particular extension point must comply with the specification set forth in the predefined policies of that particular extension point. All extensions, when executed in an operating environment, are entitled to or restricted by the same set of operating environment parameters defined by the associated extension point [Krstic; ¶36, 47-48, 52]).
Regarding claim 7, Krstic discloses the method of claim 5, wherein the third path is generated in conjunction with launching the extension of the application (in response to a request from the first application for invoking an application extension, processing logic launches the application extension within a second sandboxed environment based on a second security profile associated with the application extension [Krstic; ¶61]).
Regarding claim 9, Krstic discloses the method of claim 1, further comprising: at the extension of the application: while the extension of the application is active, storing data using the third path of the first set of one or more paths (Extension registry includes multiple entries, each corresponding one of the installed or registered extensions. Each extension entry includes, but is not limited to, extension ID, extension provider ID, and extension key. Extension ID may uniquely identify a type or class of extension services that is defined and agreed upon between an operating system provider and extension providers. Extension provider ID may uniquely identify an extension provider that provides an extension service, which may be authorized or certified by a predetermined authority. Changes to extension are made on updates or revoked [Krstic; ¶83-88]).
Regarding claim 10, Krstic discloses the method of claim 9, further comprising: while the application of the device is active, accessing the data stored using the third path of the first set of one or more paths (access is based on the selected extension [Krstic; ¶Abstract, 35-45, 87-95; Figs. 2s, 3s, 4, 8s and associated text]).
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 nonobviousness.
Claim(s) 8 and 11-13 is/are rejected under 35 U.S.C. 103 as being unpatentable over Krstic et al. (US 20150347748 A1; hereinafter Krstic) further in view of Dellinger et al. (US 20130191910 A1; hereinafter Dellinger).
Regarding claim 8, Krstic does not explicitly disclose the method of claim 5, wherein the third path is received while the device is locked; however, in a related and analogous art, Dellinger teaches this feature.
In particular, Dellinger teaches accessing application such as camera taking picture while the device is locked, the extension requirement would be different policy [Dellinger; ¶6-8]. It would have been obvious before the effective filing date of the claimed invention to modify Krstic in view of Dellinger quick access of application such as camera, music, etc., while the device the in locked mode with the motivation to increasing the effectiveness, efficiency, and user satisfaction with such devices [Dellinger; ¶22].
Regarding claim 11, Krstic does not explicitly disclose the method of claim 1, further comprising: at the extension of the application: while the device is locked, sending, via an Application Programming Interface (API), a request to authenticate a user; after sending the request to authenticate the user, receiving an indication that the device is unlocked; and after receiving the indication that the device is unlocked, performing an operation that is not accessible while the device is locked; however, in a related and analogous art, Dellinger teaches these features.
In particular, Dellinger teaches for accessing application that would require the device to be unlocked, such as reading messages, making phone calls, loading application based on notification, etc., the user would require to unlock the device with passcode or other protected credentialed based on a protected stated locked, thus would allow access to application that was inaccessible during locked state [Dellinger; ¶21-22, 175-264; Figs. 5A-5TTT]). It would have been obvious before the effective filing date of the claimed invention to modify Krstic in view of Dellinger quick access to various method of authentication to unlock the device with the motivation to increasing the effectiveness, efficiency, and user satisfaction with such devices [Dellinger; ¶22].
Regarding claim 12, Krstic-Dellinger combination discloses the method of claim 11, wherein the request for one or more paths previously provided to the extension of the application is sent after receiving the indication that the device is unlocked (full access to application such as camera, pictures, etc., after the device is unlocked [Krstic; ¶Abstract, 35-45, 87-95; Figs. 2s, 3s, 4, 8s and associated text] [Dellinger; ¶21-22, 175-264; Figs. 5A-5TTT]). The motivation to increasing the effectiveness, efficiency, and user satisfaction with such devices [Dellinger; ¶22].
Regarding claim 13, Krstic-Dellinger combination discloses the method of claim 12, further comprising: after obtaining the first content, storing at least a portion of the first content at a location remote from the device (content can be stored at various location, such as after taking pictures, sharing on the sharing extension path such as social communities (e.g., Twitter™, Facebook™, LinkedIn™, etc.) and/or non-social environments (e.g., AirDrop™, email, etc.) [Krstic; ¶94-95]).
Internet Communications
Applicant is encouraged to submit a written authorization for Internet communications (PTO/SB/439, http:ljwww.uspto.gov/sites/default/files/documents/sb0439.pdf) in the instant patent application to authorize the examiner to communicate with the applicant via email. The authorization will allow the examiner to better practice compact prosecution. The written authorization can be submitted via one of the following methods only: (1) Central Fax which can be found in the Conclusion section of this Office action; (2) regular postal mail; (3) EFS WEB; or (4) the service window on the Alexandria campus. EFS web is the recommended way to submit the form since this allows the form to be entered into the file wrapper within the same day (system dependent). Written authorization submitted via other methods, such as direct fax to the examiner or email, will not be accepted. See MPEP § 502.03.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to DAO Q HO whose telephone number is (571)270-5998. The examiner can normally be reached on 7:00am - 5:00pm.
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, Jeffrey Nickerson can be reached on (469) 295-9235. 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.
/DAO Q HO/Primary Examiner, Art Unit 2432