DETAILED ACTION
This action is responsive to the Applicant’s response filed 6/08/26.
As indicated in Applicant’s response, claims 1, 6, 11, 13, 18-20 have been amended. Claims 1-20 remain and are pending prosecution by a next office action.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1-8, 12, 19-20 is/are rejected under § 35 U.S.C. 103 as being unpatentable over Kiehtreiber et al, USPubN: 2015/0347749 (herein Kiehtreiber) in view of Lu et al, WO 2015196946 (translation) 12-30-2015, 18 pgs (herein LuZhou) and Li, Jun-ning, CN 112925589A (translation) 06-08-2021, 21 pgs (herein LiJun).
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 of at least one extension point (extension points 303-305 – para 0064) specified in an interface (host application 204, exit point 225 – Fig .2B; referred to as extension interface – para 0065) or model (see Fig. 7A, 7B), the interface or model defining one or more exits of a base software application at which the extension implementation is configured to be invoked (application 204 (space 1) -- Exit point 225 [Wingdings font/0xE0]App Extension 205 (space 2) – Fig. 2B; application 204 accesses a functionality provided by extension 205 - para 0059-0060) during execution of the base software application;
compiling the received (e.g. return the list of the identified extensions to allow the first application to select one – para 0036 ) extension implementation (step 553 – Fig. 5B; 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; reformat the translated content to be compatible with content 703 - para 0091; Conversion 704B content 703 - Fig. 7A; steps 754, 755 - Fig. 7B) to a compiled extension implementation (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 (container application and the extension can be launched inn separate sandboxed environments … based on their respective metadata and corresponding extension point – para 0037; application extension 205 … are loaded and executed in separate process address spaces … executed in a first sandboxed environment … in a second sandboxed environment – para 0047; steps 452 – Fig. 4B);
during execution (e.g. Application 204 – Fig. 4A; Launch 451 – Fig. 4B) of the base software application, triggering the at least one extension point (application 204 (space 1) [Wingdings font/0xE0] Exit point 225 [Wingdings font/0xE0]App Extension 205 (space 2) – Fig. 2B; application 204 accesses a functionality provided by extension 205 - para 0059-0060); and in response to the triggering of the at least one extension point (see above; extension point for services – para 0069), executing the compiled extension implementation in the extension runtime (e.g. para 0037, 0047; launches the application extension within a second sandboxed environment - para 0062: Launch 452 - Fig. 4B).
Kiehtreiber does not explicitly disclose implementation of at least one extension point specified in an interface or model defining
one or more callbacks of the base software application that are callable by the extension implementation to invoke functionality of the base software application;
Analogous to Kiehtreiber’s use of a base browser to invoke a application extension in form of a plug-in for the plugin to obtain extension inter-process capabilities (Kiehtreiber: para 0062) or acquire profiling data (para 0077), LiJun discloses browser extension plug-in invoking an expansion interface of a browser so that the expansion interface can dynamically load parameters sent from the plug-in, along with a target page affirmed by a verification authority to form a function page that is returned to the plug-in as call result (pg. 10-11), where the returned page data can be used by the plug-in as function page.
Further, LuZhou discloses Javacard operating as a extension application to the main application (see Abstract), where based on registration of signing data associated credentials validating between the card and the main application, the extension application invokes a function of the main application and transmit extension interface number and state thereof for the main application, upon detection of the call, to check whether the extension point corresponds with the provided extension interface number and that state of the extension point is not modified (pg. 4-5), thereby set the extension point for the extension application to active.
Hence, a call back originating from an extension application/plug-in back to the main application (e.g. a browser) so to have a specific function of main application perform verification of parameters and packaging of authorization data/configuration is recognized.
Therefore, based on the activation of entry points corresponding to one or more listed extensions registered (para 0036; para 0101, 0103; list 652, 653 – Fig. 6B) remote from the main application as set forth in Kiehtreiber and compatibility conversion of content (data conversion 755- Fig.7B) received from one of such extension, it would have been obvious for one of ordinary skill in the art before the effective filing date of the invention to implement extension configuration for the main application in Kiehtreiber so that at least one extension is provided with at least one extension point specified in an interface that defines one or more callbacks of the base software application – as set forth in Lijun and Lizhou - that are callable by the extension implementation – as in Lijun and Lizhou - to invoke a functionality of the base software application; e.g. for effect of granting/activating execution of the extension; because
remotely stored extension modules or software when fetched and selected from outside of the main/base environment might not guarantee authenticity and integrity of their content or identification therefore necessitate additional verifications or attestation by/from within the host environment by which to affirm on their being able to operate or execute, and by providing the base/host application with a function (“callback” ) callable by the extension implementation, this verification can be ascertained or confirmed – as set in Lizhou main application – for fear that a non-authenticated or compromised extension would give ingress to a malicious entity (vulnerability attack) to infest the base application and/or propagate a deep data non-compliancy issue therein to the rest of the host system.
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 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 extension implementation 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 (e.g. 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, the interface or model defining (1) one or more exits of a base software application at which the extension implementation is configured to be invoked during execution of the base software application, or (2) one or more callbacks of the base software application that are that are callable by the extension implementation to invoke functionality of the base software application;
compiling the received extension implementation to a compiled extension implementation and deploying the compiled extension implementation to an extension runtime;
during execution of the 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 in the extension runtime.
( 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 receive an extension implementation that provides an implementation of at least one extension point specified in an interface or model, the interface or model defining (1) one or more exits of a base software application at which the extension implementation is configured to be invoked during execution of the base software application, or (2) one or more callbacks of the base software application that are that are callable by the extension implementation to invoke functionality of the base software application;
computer-executable instructions that, when executed by the computing system, cause the computing system to compile the received extension implementation to a compiled extension implementation and deploying the compiled extension implementation to an extension runtime;
computer-executable instructions that, when executed by the computing system, cause the computing system to, during execution of the base software application, trigger the at least one extension point; and
computer-executable instructions that, when executed by the computing system, cause the computing system to, in response to the triggering of the at least one extension point, execute the compiled extension implementation in the extension runtime.
( All of which having been addressed in claim 1)
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 Lu et al, WO 2015196946 (translation) 12-30-2015, 18 pgs (herein LuZhou) and Li, Jun-ning, CN 112925589A (translation) 06-08-2021, 21 pgs (herein LiJun), further 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’s 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 one or more of 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.
Claims 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 Lu et al, WO 2015196946 (translation) 12-30-2015, 18 pgs (herein LuZhou) and Li, Jun-ning, CN 112925589A (translation) 06-08-2021, 21 pgs (herein LiJun), further 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.
Thus, 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 an 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 Lu et al, WO 2015196946 (translation) 12-30-2015, 18 pgs (herein LuZhou) and Li, Jun-ning, CN 112925589A (translation) 06-08-2021, 21 pgs (herein LiJun), further 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 extension 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 Lu et al, WO 2015196946 (translation) 12-30-2015, 18 pgs (herein LuZhou) and Li, Jun-ning, CN 112925589A (translation) 06-08-2021, 21 pgs (herein LiJun), further 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 restrictions 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 messages, similar to a authority configured with rules to
officially connect an extension to a base application, in that messages exchanged between these
applications are directed to this extension connector authority- referred herein as (*) - in which the
message content is stored and verified for conformance. Thus, use of an "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 being parsed by the DR so to establish whether message-provided credentials fulfill a required trust (pairing of shared secret keys) as well as satisfy requirements of policies associated with a target entity (a trusted group) to which the connection is being sought (pg. 17-18) per use of a connection granting authority 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 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: via 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 Lu et al, WO 2015196946 (translation) 12-30-2015, 18 pgs (herein LuZhou) and Li, Jun-ning, CN 112925589A (translation) 06-08-2021, 21 pgs (herein LiJun), further 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 an 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.
Response to Arguments
Applicant's arguments filed 6/8/26 have been fully considered but they are not persuasive. Following are the Examiner’s observations in regard thereto.
(A) The Applicant has submitted that the SDK compilation and invoking of extension services in Kiehtreiber does not amount to an integrated sequence as these activities in Kiehtreiber occur at different times with different actors, not as a request for a extension implementation directed from a host application (Applicant's Remarks pg. 7). The claim language of claim does not recite “receiving” an extension implementation request initiated from a host/based application (emphasis here)
(B) The Applicant has submitted that in Kiehtreiber, the compiling against SDK libraries by a developer occurs before the system receives anything about generating a extension implementation (Applicant's Remarks pg. 7 bottom). The compiling and formatting as cited in Kiehtreiber entails preparing one extension implementation selected from a list to make it compatible with the context of the base application (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; reformat the translated content to be compatible with content 703 - para 0091; Conversion 704B content 703 - Fig. 7A; steps 754, 755 - Fig. 7B); and allegation that Kiehtreiber at no time teaches receiving an extension application then compile it is deemed largely non-convincing, notably when the feature recited as “compiling a received extension” is part of an amendment (emphasis here), making any premature raise of patentability merits thereof statutorily misplaced or improper, since the ground of the argument seems to be introduced way before the Office has rendered a prima-facie prosecution of the amended language. In other words, the claim language (prior to the Amendment) does not clearly set a time line as to when (or by whom) a request is being initiated to receive an extension SW and when ( and by whom) a compilation for it starts.
( C ) The Applicant has submitted that Kiehtreiber does not provide “extension point specified in a interface or model” now recited as limitation (1) and (2) in claim 1 (Applicant's Remarks pg. 8-9). Raise of patentability merits of a newly added limitation is deemed either premature or largely MOOT in view of the latest grounds of rejection being presented to meet these language changes.
In all, the claims as amended and submitted will stand rejected by the above Office action which has been necessitated by the claims amendment.
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 extension fee 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 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.
/Tuan A Vu/
Primary Examiner, Art Unit 2193
August 24, 2026
Prosecution Insights