DETAILED ACTION
This action is responsive to the Application filed 4/08/2024.
Accordingly, claims 1-20 are submitted for prosecution on merits.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claim 6 is rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Claim 6 recites "the exit implementation" (accesses … data structure) limitation in line 2. There is insufficient antecedent basis for this “the exit implementation” limitation in the claim.
This limitation will be treated as though the model accesses the data structures. Correction is required.
Claim Rejections - 35 USC § 102
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)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
(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-8, 12, 19-20is/are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Kiehtreiber et al, USPubN: 2015/0347749 (herein Kiehtreiber).
As per claim 1, Kiehtreiber discloses a computing system comprising:
at least one memory; one or more hardware processor units coupled to the at least one memory; and one or more computer readable storage media storing computer-executable instructions that, when executed, cause the computing system to perform operations comprising:
receiving an extension implementation (request received from a host application for invoking the extension – para 0039; request received from application 204 … for a particular type of extension services – para 0046; logic receives a request … inquiring a particular extension service … associated with a particular extension point – para 0088; receive 651 – Fig. 6B) that provides an implementation (App extension 205, photo Editing Ext – Fig. 2B; extension point for photo editing – para 0069) of at least one extension point specified in an interface (host application 204 [Wingdings font/0xDF][Wingdings font/0xE0] exit point 225) or model (refer to claim 2);
compiling the extension implementation (translation extension service – para 0091; extension 702 includes data conversion code 704A – para 0090; execute conversion code 753 – Fig. 7B; extension 205 have to be compiled using an SDK or libraries – para 0059; extension 302 may be … compiled with a specific set of libraries corresponding to extension point 304 – para 0065) to a compiled extension implementation (launches extension 702 to provide translation services, conversion code 704A – para 0091; para 0092; translation 702: conversion code 704A, translator 705 – Fig. 7A) and deploying the compiled extension implementation to an extension runtime (reformat the translated content to be compatible with content 703 – para 0091; Conversion 704B[Wingdings font/0xE0]content 703 – Fig. 7A; steps 754, 755 – Fig. 7B);
during execution (e.g. invoke application extension 205 at runtime – para 0046) of a base software application, triggering (predefined application programming interfaces or communication protocols that allow a client being a first application … to access and provide a service from … to another client. A service provided by an extension point – para 0035; invoking an application extension (e.g. plugin) … launches the application extension within a second sandboxed environment – para 0062 – Note0: use of communication protocols combined with predefined APIs to allow a first application to access and invoke a service associated with an extension point reads on triggering during runtime of a base application the at least one extension point; see application 204 invoke application extension 205 at runtime – para 0046) the at least one extension point; and
in response to the triggering (see Note0 from above; application programming interfaces or communication protocols from above; set of policies and/or communication protocol (e.g. APIs) – para 0059; para 0046) of the at least one extension point, executing (e.g. extension 205 is launched and executed in a second sandboxed environment – para 0047; launches the application extension within a second sandboxed environment – para 0062) the compiled extension implementation.
As per claim 2, Kiehtreiber discloses computing system of claim 1, the operations further comprising:
compiling the model to provide a compiled model (see Fig. 3B from below; IPC framework – para 0047 - Note1: extension points and individualized sandboxes for each to be configured via a inter-process communication framework and IPC services thereof – para 0059 - reads on instance of a security model being compiled as an inter-process communication framework to enable/facilitate interactions, data exchange between client/application extension instances – para 0072 - associated with respective extension points – see Fig. 3B - so not to compromise the overall security model – see para 0073); and
deploying the compiled model (IPC service module 315 – para 0070; invokes the IPC service module 315 to facilitate IPC communications between client 301 and 302 via extension point – para 0059; IPC framework … to allow an application to access certain system services … to share data – para 0073; IPC service module 315 – Fig. 3B) to the extension runtime, wherein the compiled extension implementation (refer to claim 1) accesses the compiled model (module 3156 [Wingdings font/0xDF][Wingdings font/0xE0] client extension 302 – Fig. 3B) during execution of the compiled extension implementation (IPC service module 315 to facilitate IPC communications between client 301 and 302 via extension point – para 0059).
As per claim 3, Kiehtreiber discloses computing system of claim 1, wherein
the interface or model provides at least one function (share command, sharing extension point – para 0095; Each extension point is associated with a set of APIs to allow one application to access a predefined functionality or obtain a service – para 0083; XPC services … these services which implement a specific function or perform a designated task … services which are available only to the application represented by the application bundle – para 0079; there may be services … in the same or different frameworks – para 0080; service to translate … to view … to apply a filter – para 0069) of the base software application that can be called by an extension implementation and
the extension implementation comprises a call to the at least one function (Note2: APIs setting within a main application to enable a predefined service function – para 0083; sharing services, e.g. Fig. 8A, para 0095 - among a plurality thereof – para 0080, para 0069 - provided via respective extension point – Fig. 3B - to be obtained via API/plugin set in the main application reads on the overall service framework including a function – e.g. sharing service - that can be called by an extension implementation so that the invoked function can provide a extension service -e.g. to share, to translate, to view, to filter - to be rendered via IPC communication linkage or APIs or plugin – para 0046 - setting between the main application and the extension implementation).
As per claim 4, Kiehtreiber discloses computing system of claim 1, wherein the extension runtime is integrated with a runtime (invoke application extension 205 at runtime – para 0046) of the base software application.
As per claim 5, Kiehtreiber discloses computing system of claim 1, wherein the extension runtime is separate from a runtime (second sandboxed environment 207 – para 0045) of the base software application.
As per claim 6, Kiehtreiber discloses computing system of claim 1, wherein the model (refer to claim 2) specifies one or more data structures (share sheet, share sheet having actual content – para 0042; virtual addresses – para 0045) and the exit implementation (refer to USC 112 Rejection where exit implementation is treated as model) accesses at least one data structure (set of ranges of virtual addresses – para 0045; share sheet … content – para 0042; Fig. 8A) of the one or more data structures.
As per claim 7, Kiehtreiber discloses computing system of claim 1, the operations further comprising:
generating metadata (e.g. XPC services … these services which implement a specific function or perform a designated task … services which are available only to the application represented by the application bundle – para 0079; the extension and the container application … released in a bundle, the bundle includes container application and its metadata describing the container application and the extension and its metadata describing the extension – para 0037) describing the extension implementation (metadata associate with extension 302 – para 0065); and
configuring the base software application to use the extension implementation based
at least in part on the metadata (e.g. installer parses the metadata of the bundle and recognizes that application extension 205 is designed for application 204 – para 0046; entitlements may be specified as an attribute or metadata – para 0054).
As per claim 8, Kiehtreiber discloses computing system of claim 1, wherein the extension runtime is a sandboxed environment (second sandboxed environment – para 0045, 0047, 0062, 0076)
As per claim 12, Kiehtreiber discloses computing system of claim 1, wherein the compiled extension implementation (refer to claim 2) is used for processing extension point triggers for multiple clients (extension framework is a sharing extension point … to share content in a community or another user – para 0040; extension points 303-305 to allow various clients … access via extension points 303-305 … one client as a host … to obtain a predefined service or services provided by another client – para 0064; client301 and client 302 may be compiled and linked …associated with extension point 380 – para 0070; IPC framework … facilitate … exchange or messages amongst the clients – para 0072)
As per claim 19, Kiehtreiber discloses a method, implemented in a computing system comprising at least one hardware processor and at least one memory coupled to the at least one hardware processor, the method comprising:
receiving an extension implementation that provides an implementation of at least one
extension point specified in an interface or model;
compiling the extension implementation to a compiled extension implementation and
deploying the compiled extension implementation to an extension runtime;
during execution of a base software application, triggering the at least one extension
point; and in response to the triggering of the at least one extension point, executing the
compiled extension implementation.
(all of which having been addressed in claim 1)
As per claim 20, Kiehtreiber discloses one or more computer-readable storage media comprising: computer-executable instructions that, when executed by a computing system
comprising at least one hardware processor and at least one memory coupled to the at least
one hardware processor, cause the computing system to respectively:
receive an extension implementation that provides an implementation of at least one extension point specified in an interface or model;
compile the extension implementation to a compiled extension implementation and deploying the compiled extension implementation to an extension runtime;
during execution of a base software application, trigger the at least one extension point; and
in response to the triggering of the at least one extension point, execute the compiled extension implementation.
(all of which having been addressed in claim 1)
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 9-10 is/are rejected under § 35 U.S.C. 103 as being unpatentable over of Kiehtreiber et al, USPubN: 2015/0347749 (herein Kiehtreiber) in view of Tiwary et al, USPubN: 2021/0124822 (herein Tiwary)
As per claims 9-10, Kiehtreiber does not explicitly disclose computing system of claim 1, wherein the extension implementation is compiled to a portable binary format; wherein the portable binary format is WebAssembly.
Providing portable binary format (para 0025) compiled as WebAssembly module to implement a WASM for a security application extension (SGX – para 0034-0035) is shown in Tiwary WASM process (Fig. 2) where a sandbox of JavaScript type environment is utilized to decode the web-assembly module and load it onto compatible web platforms or browser runtime (para 0020)
Therefore, it would have been obvious for one of ordinary skill in the art before the effective filing date of the invention to implement extension to security application in Kiehtreiber so that software provided for an extension implementation is a portable binary format which can be compiled as Web-assembly code as in Tiwary; because
particular portable binary format compiled as WebAssembly can implement a WASM for use in sandboxed (protected) environments that are typically compliant with the web-oriented aspect of security applications, such that implementing extension of this security environment/runtime -as in Tiwary - in terms of WebAssembly code would facilitate the native code underlying these environments to match with Javascript-based extension or browser-based functionality of the WASM according to which, a WebAssembly script compilation of a standard portable binary format can be easily parsed with native Web/browser interpreter (of a security environment) to carry out the function or service functionality predefined for one of such application extensions.
Claim 11 is/are rejected under § 35 U.S.C. 103 as being unpatentable over of Kiehtreiber et al, USPubN: 2015/0347749 (herein Kiehtreiber) in view of Hendrey et al, USPN: 2023/0315428 (herein Hendrey) and Bruening et al, USPubN: 2006/0190924 (herein Bruening)
As per claim 11, Kiehtreiber discloses computing system of claim 1, wherein executing the compiled extension implementation comprises instantiating the exit implementation (application 204 and application 205 communicates via … IPC which may be brokered by corresponding extension point 225 … extension point 225 … that have been defined by … and agreed upon by the extension service … to conform to a set of policies and communication protocols – para 0059; Exit point 225 – Fig. 2B) to provide an instantiated exit implementation,
Kiehtreiber does not explicitly disclose the operations further comprising: caching the instantiated exit implementation.
Bruening discloses runtime control module (RCM - Fig. 1-2) operating with context switch having allocation of cache lines to store control flow instructions in relation to tracing, basic block caching and indirect branch (para 0027; Trace Cache, basic block cache - Fig. 3); where for a given branch exiting a base code flow (jmp, mov - Fig. 5A), an exit stub linking to its actual fragment (the linked state as layout from code cache – Fig. 6) enable switching from one state to another state which takes a 32-bit store that is to be atomic within a cache line (para 0034), where address targets of the stub exits are materialized a priori in a fragment of code cache (para 0030; fragment 330 – Fig. 8) so to enable transfer control to the context switch and return back from the switch using management support of the RCM pre-registering of reference information - for a jump instance - in form of caching exit points for one such (context switch jump) stub. Hence caching exit implementation instances associated with tracing of branch or a context switch from a base program flow is recognized.
Hendrey discloses an extensibility platform or FMM (para 0252) to adapt and extend solutions to productivity of cloud system (para 0088), in augmenting capabilities of the platform so as to benefit solution to which the tenants are entitled to (para 0094), the extensibility platform providing ability to query information associated with Metrics, Events, Logs, and Traces (MELT) signals (para 0093) as part of added observability to the tenants seeking solution from microservices (para 0105); where compilation and execution plan (Fig. 13) associated with a query engine may be cached with a schema service (para 0180), resulting in quick retrieval of the MELT data allowing these cached entities to be analyzed/correlated for a graphical development. Hence, caching of a (query) service provided as extended observability provision to users of a extensibility platform is recognized.
It would have been obvious for one of ordinary skill in the art before the effective filing date of the invention to implement the context switch underlying a jump from a base application runtime into execution context of a extension implementation in Kiehtreiber’s system so that instance of each such context switch is accompanied with control flow management and registration of exit point information would be configured with runtime registering according to which, a cache – as the caching of schema service per Hendrey extended query service - can be configured to store one or more of such instantiated exit implementations that allow runtime context switch – as in Bruening - between the base application and an extension application; because
caching of exit implementation associated with context switch by which a main application can allow control to be passed to a extension application such as a extended query service as set forth above, would enable runtime associated with the extension implementation instance to record exit points at which to instantaneously invoke a branch/jump to transfer away control of the base application onto an extended functionality (a query service) to which is linked an extension point and a registered point in cache at which control is to promptly returned to the main application as soon as the extended functionality finishes its execution, the use of cached data boosting performance throughput of the extensibility platform in that delay associated with fetching of registered runtime information for one or more of such extension context switch instances is substantially minimized.
Claims 13-15 is/are rejected under § 35 U.S.C. 103 as being unpatentable over of Kiehtreiber et al, USPubN: 2015/0347749 (herein Kiehtreiber) in view of JP 5368027B, (translation) 12-18-2013, 39 pgs (herein ‘027)
As per claims 13-15, Kiehtreiber does not explicitly disclose computing system of claim 1, wherein executing the compiled extension implementation comprises:
(i) from the base software application, sending to an extension proxy of the execution runtime a call to execute the compiled extension implementation; and with the extension proxy, calling the compiled exit implementation;
(ii) with the extension proxy, translating the call from the base software application to a format used by the extension runtime.
(iii) wherein translating the call comprises converting a parameter value from a first datatype to a second datatype.
In Kiehtreiber, extension application can be implemented as a service functionality of data sharing among client tiers (sharing photo editing – Fig .6A; Share interface, thumbnail image, share command 821 – Fig. 8A; sharing extension creates a share sheet 852, post the content based on the sheet view 853 – Fig. 8B) including presentation of common data or shared content by way of a command launched from a base application.
Provision of a runtime proxy sent from a source device to request common data display and packaging by a receiving device is shown in device-to-device command and network control by ‘027, where a proxy sent (requesting device 122 can also send a reply by proxy – pg. 33) from the source device initiating the request is intercepted by a translator server disposed between the receiving device and the request transmitting device, whereby data (request command) to be sent to the receiving device and data (e.g. response status, returned value) returned therefrom can be translated into source/target compliant protocol format or native type (pg. 34) of the requesting device.
Hence, use of an extension proxy from a source application to initiate proper format of execution runtime related a call command to execute the compiled extension implementation such as to display of common data is recognized, and transmission of proxy from the source application to cause translation of a extension command into a format compliant with a extension runtime via a translator service is recognized; and a translation instance thereby to convert parametric data/value from a first datatype to a second datatype to facilitate interpretation at respective environment (requesting device and common data display device) is recognized.
Therefore, it would have been obvious for one of ordinary skill in the art before the effective filing date of the invention to implement the sharing extension in Kiehtreiber as part of the model that bundles multi-services with IPC framework so that executing the compiled extension implementation under this IPC framework would include
1) sending via an extension proxy of the execution runtime, a call from the base application to execute the compiled extension implementation; and with the extension proxy – as in ‘027, calling the compiled exit implementation underlying the instance of the extension implementation;
2) with the extension proxy, translating the call from the base software application to a format (parametric value compliancy) used by the extension runtime – as via a translator service in ‘027
3) wherein translating the call comprises converting a parameter value from a first datatype to a second datatype, per the translation of extension command and of returned values/data from the executing device in response to the request – as per the translator in ‘027; because
a proxy is configured to facilitate data conversion between different host environments and communication protocols under which the environments operate, and by providing a proxy service established between a base/source environment application that requests execution of a compiled extension service/model (share command as in Kiehtreiber) and the extension environment destined to carry out the extension SW command, the disparity between protocols governing each environment can be mitigated or resolved by a protocol format translation of the proxy using information characterizing either the source application or the destination environment, where the format disparity mitigating function of the proxy can also be used to convert display setting of a first environment to match that of a second environment when data from either environment is being shared or displayed at a different host context - as illustrated in the command to execute a sharing extension in Kiehtreiber; the proxy-based runtime translation – as set forth above - further capable of resolving disparity between application software that implements the sharing extension in that parametric values/types from each environment software are reconverted into a format that suits the native context in which the extended software (sharing extension) is being requested from a base application.
Claims 16-17 is/are rejected under § 35 U.S.C. 103 as being unpatentable over of Kiehtreiber et al, USPubN: 2015/0347749 (herein Kiehtreiber) in view of Yang et al, CN 109314694B (translation) 11-19-2021, 27 pgs (herein Yang)
As per claims 16-17, Kiehtreiber does not explicitly disclose computing system of claim 1, the operations further comprising:
in response to the triggering of the at least one extension point, sending a message to
an extension connector to execute the compiled extension implementation.
the operations further comprising: by the extension connector, storing a context for the message.
In Kiehtreiber, the IPC framework is set to recognize request for connection from a base application or an extension service to the IPC framework in that for a agreed-upon IPC service name, the base application and extension application can establish connection with the service name, thereupon to start send/receive messages via the connection (para 0072), where message exchanged between base application 204 and extension application 205 undergo protocol verification according to restriction or entitlements that a extension must comply to predefined policies (para 0037, 0076). Hence, use of a policies verification layer to establish whether messages sent/received between a base application and an extension application are compliant to predefined restrictions, entitlement policies entails use of a extension validator that acts as an authority to enable the base application and extension application to exchange message, similar to a authority configured with rules to officially connect an extension to a base application, in that messages exchanged between these application are directed to this extension connector authority– referred herein as (*) - in which the message content is stored and verified for conformance. Thus, use of a “extension connector” based on whose capability messages resulting from extension point trigger are parsed and validated per their content would have been obvious.
Yang discloses reconfiguration machine to group management in machine system using a registrar device (DR) to reconfigure machine-to-machine inter-operation and communication, in which the type of connection of a group authority may be different from the connection type establishing a initial connection with a register endpoint, and that use of registrar entity to reconfigure connection in accordance to a given type of NW connection would provide safety to the connection as intended, affording therewith security constraints and qualification provided from connection parameters, for a group (pg. 16). That is, content of message sent to establish a connection is parsed by the DR in order to establish whether credentials for fulfilling the required trust (pairing of shared secret keys) as well as satisfying requirements of policies associated with a target entity (a trusted group) to which the connection is being sought (pg. 17-18); hence provision of a connection authority to establish whether a requested connection communicated via a message can be granted is recognized.
Thus, it would have been obvious for one of ordinary skill in the art before the effective filing date of the invention to implement machine-to-machine message communication associated with triggering a extension point in Kiehtreiber IPC framework system so that in response to the triggering of the at least one extension point, the operations associated with messaging communication redirect one such a message request – as message requesting a connection in Yang - to an extension connector – as per a DR in Yang or verification authority as in (*) - to approve or grant the requested connection with which to execute the compiled extension implementation; the operations further comprising: by the extension connector, storing a context for the message and parsing content thereof to establish compliancy to policies and credentials on trust – as per the DR in Yang; because
policies rules setting and security restrictions reinforced with cryptographic-based authentication associated therewith being functionality core for NW portals set between often different environments (that intent to inter-communicate) and configured to verify whether connection for the communicating should be granted or warranted in accordance to trustiness of the respective sources, of devices sending or receiving the data would not only provide early filtering of requests for establishing connection intended for subsequent transfer of data -- from one environment of a given NW protocol to another environment governed by a different NW protocol – as this would act as a security shield in prematurely denying connectivity and preventing passage of information originating from untrusted or unverified source, as well as vulnerability or integrity attacks onto protected resources of a given environment, whereas
specific provision of a software portal between a base application and an extension service, each governed by different NW protocol and architectural, environmental constructs, on basis of a need to connect triggered by extension point as in Kiehtreiber in form of an authority component capable of operations such as intercepting requests for establishing a connection (initiated by a base application) by which a requested extension service as in Kiehtreiber can be carried out would fulfill the trustiness verification, enable cryptographic authenticating and the policies compliancy check by which disparate environments can be granted inter-communication, so that
for a given session established by this connection authority in granting inter-platform communication, data of a different protocol or given native context(e.g. base application platform) can be translated under provision of extension point package, into proper format that would suit their being used or processed at a destination host to preclude potential format conflicts caused by native-to-native disparity, e.g. to thereby promulgate smooth execution of an extension application at a extension host being triggered for execution from a different environment as result from an extension point as set forth in Kiehtreiber.
Claim 18 is/are rejected under § 35 U.S.C. 103 as being unpatentable over of Kiehtreiber et al, USPubN: 2015/0347749 (herein Kiehtreiber) in view of Gao et al, WO 2012142854, (translation) 10-26-2012 (herein Gao)
As per claim 18, Kiehtreiber does not explicitly disclose computing system of claim 1, the operations further comprising:
in response to the triggering of the at least one extension point, determining a version
of the extension interface to be executed.
Gao discloses options to application development in need of a RemoteAppBean routed under an @AppName as part of request configuration to support a inclusion of grayscale publishing functionality or App (pg. 28) via an extension interface (pg. 17) with exposure of AppBean to be called, using a proxy class (pg. 39) to communicate request and receive response to the request or development need to access the RemoteAppBean whereby the developers can select and incorporate a version of the grayscale App (pg. 8) in the purpose to extend a User publishing context (pg. 29) where corresponding versions of the (grayscale) publishing App instances (pg. 38) available from a library and identified via assistance of a dependency information management in the framework are presented (pg. 52) via an extension plug-in for the developer’s selection and integration into user publishing App context. Hence, assistance from a dependency management in support for extending a developer grayscale publishing application with presentation of versions of application interface or app to be executed as part of implementing an extension via extension plug-in presenting of selectable version options is recognized.
Thus, based on Kiehtreiber registering of extension service instances in repository for query, identification via a profile, setting of entitlements, acquisition and subsequent integration into an extension application (para 0066) it would have been obvious for one of ordinary skill in the art before the effective filing date of the invention to implement extension functionalities contributing to the multi-service provision under Kiehtreiber’s IPC framework so that the extension software or application interface instances thereof are pre-stored functionalities made available to development endeavors or extension implementation over an existing development context, such that in response to the triggering of the at least one extension point as set forth per Kiehtreiber’s framework, management support of one such extension application would perform determination of a version of the proper extension interface or App instance - in accordance to identification of library Apps and plug-in support set forth in Ga - where the extension code elected version can be incorporated into a extension service (under Kiehtreiber’s IPC framework) then executed in response to an extension point being triggered from a base application; because
use of a plug-in associated with a management layer for collecting and presenting of extension software choices ( extension-related application interfaces, Apps or executables) in support of rendering a given service requested as extension under the multi-services IPC framework in Kiehtreiber, would not only assist implementation of a triggered extension point with dependency analysis and identification/discovery of the most relevant software instances that befit a service deployable via the IPC framework in accordance to certain NW protocols, HW restrictions and native format associated with a host environment,; but would also use the dependency analysis and security check by this management layer to gather or update and route a discovery list of software choices into a list of UI options by which a developer can select one version and thereby configure a targeted extension service triggerable from an extension point purported to activate an extension functionality (sharing extension) that is hosted in a runtime environment different than the developer current platform.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Tuan A Vu whose telephone number is (571) 272-3735. The examiner can normally be reached on 8AM-4:30PM/Mon-Fri.
If attempts to reach the examiner by telephone are unsuccessful, the examiner's supervisor, Chat Do can be reached on (571)272-3721.
The fax phone number for the organization where this application or proceeding is assigned is (571) 273-3735 ( for non-official correspondence - please consult Examiner before using) or 571-273-8300 ( for official correspondence) or redirected to customer service at 571-272-3609.
Any inquiry of a general nature or relating to the status of this application should be directed to the TC 2100 Group receptionist: 571-272-2100.
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).
/Tuan A Vu/
Primary Examiner, Art Unit 2193
March 02, 2026