Source: http://www.google.com/patents/US7836456?dq=7,069,055
Timestamp: 2016-12-11 14:32:28
Document Index: 35050781

Matched Legal Cases: ['Application No. 06256576', 'Application No. 07250044', 'application No. 06256576', 'application No. 07250044', 'Application No. 06256576', 'Application No. 07250044', 'application No. 06256576', 'application No. 07250044']

Patent US7836456 - Seamless extension of shareable interface mechanism to servlet and extended ... - Google PatentsSearch Images Maps Play YouTube News Gmail Drive More »Sign inPatentsIn a smart card system in which applications executing in different execution contexts are allowed to communicate with each other only through shareable interface objects (SIO's), a registry mechanism is provided to mediate in inter-application communication between legacy applets, extended applets and...http://www.google.com/patents/US7836456?utm_source=gb-gplus-sharePatent US7836456 - Seamless extension of shareable interface mechanism to servlet and extended applet model for inter-application communicationAdvanced Patent SearchTry the new Google Patents, with machine-classified Google Scholar results, and Japanese and South Korean patents.Publication numberUS7836456 B1Publication typeGrantApplication numberUS 11/590,953Publication dateNov 16, 2010Filing dateOct 31, 2006Priority dateOct 31, 2006Fee statusPaidPublication number11590953, 590953, US 7836456 B1, US 7836456B1, US-B1-7836456, US7836456 B1, US7836456B1InventorsThierry P. Violleau, Tanjore Ravishankar, Matthew R. HillOriginal AssigneeOracle America, Inc.Export CitationBiBTeX, EndNote, RefManPatent Citations (8), Non-Patent Citations (16), Referenced by (7), Classifications (8), Legal Events (4) External Links: USPTO, USPTO Assignment, EspacenetSeamless extension of shareable interface mechanism to servlet and extended applet model for inter-application communication
US 7836456 B1Abstract
In a smart card system in which applications executing in different execution contexts are allowed to communicate with each other only through shareable interface objects (SIO's), a registry mechanism is provided to mediate in inter-application communication between legacy applets, extended applets and servlets. A request by a client application for a SIO of a server application in a different execution context is routed to the registry mechanism by the system. Dependent on what types the client and server applications are, the registry mechanism provides call interfaces as would be expected by the applications to enable passing the SIO from the server application to the client application. In one embodiment, servlets and extended applets may also register and unregister their SIOs dynamically with the registration mechanism.
This application is related to U.S. patent application Ser. No. 11/511,948 entitled “METHOD AND APPARATUS FOR DATA TRANSFER BETWEEN ISOLATED EXECUTION CONTEXTS”, filed by THIERRY VIOLLEAU et al. on Aug. 28, 2006, the entire contents of which is hereby incorporated by reference for all purposes as if fully set forth herein.
Smart cards are wallet-size or smaller devices with embedded integrated circuits. A smart card typically comprises a processor and memory. Smart cards come with various tamper-resistant properties and are capable of storing vital information and hosting sensitive applications in a secure manner. Smart cards implementing Java Card technology further enhance application security by executing applications in different firewalls, or execution contexts. Under this enhanced security scheme, data, methods and/or objects inside a server application can only be accessed through shareable interface objects (SIO's) by a client application executing in a different execution context.
In order to obtain a SIO from a server application, a client application uses a multi-step procedure. First, the client application is required to have specific knowledge of an application identifier for the SIO and prepare a binary representation of that application identifier. Second, the client application is required to invoke a first system call “JCSystem.lookupAID( )” with the binary representation prepared. Third, the system returns a corresponding application identifier object to the client application if the application identifier is determined as genuine. Fourth, the client application is required to invoke a second system call “JCSystem.getAppletShareableInterfaceObject( )” and pass the returned application identifier object in the call. Fifth, the system in turn invokes a method supplied by the server application, “Applet.getShareableInterfaceObject( )” to obtain the SIO. The server application may implement logic in the aforementioned method to either allow or deny access to the SIO by the client application. If the access is allowed, the SIO is passed from the server application to the client application via the system.
In a smart card system in which applications executing in different execution contexts are allowed to communicate with each other only through SIO's, applications on Java Cards can be classified into three types. The first type of applications is a legacy applet operating in accordance with the legacy operating model. An application of this type only understands the aforementioned multi-step procedure. As a client who asks for a SIO, a legacy applet makes two system calls. As a server who provides a SIO, a legacy applet implements a method for the system to call and logic to deny or give the SIO. Next, the second type of applications is an extended applet, which may operate in accordance with either the legacy operating model or a new operating model. The new operating model allows a SIO to be identified by either an application identifier or a URI. Thus, a SIO exposed by an extended applet may be identified by an application identifier (in a SIO registry). Finally, the third type of applications is a web application such as a servlet, operating in accordance with the new operating model. Under the new operating model, a SIO exposed by a servlet may be identified by a URI (in a SIO registry).
FIGS. 1-3 are diagrams illustrating entities involved in inter-application communication across execution contexts, in accordance with various embodiments of the present invention. As shown, smart card system 100 comprises one or more execution contexts 102 and a registry mechanism 104. For purposes of the present invention, the smart card system 100 may be any type of smart card, including but not limited to, a smart card implementing the Java Card technology. The smart card system 100 provides a framework in which applications are executing in execution contexts and inter-application communication across execution contexts is enabled through shareable interface objects (SIO's). A shareable interface object (SIO) as referenced herein is an object which has been designated by the owning server application as accessible from a client application context. Only the methods defined in the Shareable Interface (SI) are accessible to the client.
When a first application 106 on a smart card wishes to communicate with a second application 120 executing in a different execution context on the same card, the first application 106 can send a request for a SIO 108 exposed by the second application 120 to the registry mechanism 104. The request would comprise a set of identification information for the SIO requested and zero or more parameters. If the first application 106 is a servlet or extended applet, the request can be made by invoking a method directly provided by the registration mechanism, “JCRegistry.lookup( )”, in an embodiment. If the first application 106 is a legacy applet, it can follow the multi-step procedure in the legacy operating model by calling JCSystem.lookupAID( ) to obtain an AID object and then, based on the returned AID object, calling JCSystem.getAppletShareableInterfaceObject( ) to obtain an interested SIO. On a smart card with present invention implemented, these two calls would be routed to the registry mechanism 104 by the system 100. Thus, whether the first application is a legacy applet operating in the legacy operating model or a servlet or extended applet operating in the new operating model, the registry mechanism 104 receives the request for the SIO 108 (step 410 of FIG. 4).
Upon receiving the request, the registry mechanism 104 determines whether the second application 120 operates in accordance with the legacy operating model or the new operating model (step 420 of FIG. 4). In one embodiment, this determination can be made by accessing the SIO lookup registry 112, finding an entry 114 in the SIO registry that matches the set of identification information received in the request from the first application 106, and determining whether a reference 116 in the matching entry is null. If the reference 116 in the entry 114 is null, the second application 120 is determined as a legacy applet (as 120-1 shown in FIG. 1) operating in the legacy operating model. In this case, the registry mechanism invokes a legacy method 110 such as “Applet.getShareableInterfaceObject( )” to obtain the SIO (step 430 of FIG. 4). On the other hand, if the reference 118 in the matching entry 114 points to a SIO factory object 210, the second application is determined to be either a servlet (120-2 in FIG. 2) or an extended applet (120-3 in FIG. 3). A further determination may be made as to whether the second application is a servlet or an extended applet. For example, in a particular embodiment, the registration mechanism 104 may determine whether a qualifier such as “uri” or “aid” in a corresponding SIO identifier 116 of the matching entry 114. If the qualifier is “uri”, then the second application is determined to be a servlet. Otherwise, if the qualifier is “aid”, then the second application is determined to be an extended applet. If the second application is determined to be an extended applet, then the registration may determine whether the extended applet is operating in the legacy model or operating in the new operating model. In one embodiment, the registration mechanism may invoke a system call or a call provided by the second application to determine whether the second application is operating under the legacy model or not (step 440 of FIG. 4). In one embodiment, the registration mechanism defaults to the new operating model when the second application is determined to be an extended applet and after the registration mechanism has determined that the second application does not use the legacy operating model for the SIO requested by the first application. In any event, if the second application is determined to be a servlet, the registry mechanism 104 invokes the SIO factory object (either 210-2 in FIG. 2) to cause an SIO to be created (step 450 of FIG. 4). If the second application is determined to be an extended applet operating in the new operating model, the registry mechanism 104 invokes the SIO factory object (210-3 in FIG. 3) to cause an SIO to be created (step 450 of FIG. 4). On the other hand, if the second application is determined to be an extended applet operating in the legacy model, the registry mechanism invokes a legacy method 110 such as “Applet.getShareableInterfaceObject( )” to obtain the SIO (step 430 of FIG. 4). Thereafter the registry mechanism 104 provides the SIO 108 to the first application 106 to enable it to communicate with the second application using the SIO from that point on (step 460 of FIG. 4).
In one embodiment, if a first application operates in the new operating model, it can send a request containing a SIO pattern that matches one or more SIO identifiers, rather than a SIO identifier, thereby avoiding hard-coding any specific SIO identifier as would be required in the legacy operating model. In one embodiment, this “wild card” mechanism is intended only for event SIOs and not for direct synchronous communications between applications. In such embodiment, the event SIOs are delivered asynchronously to the requesting application. For example, a first application may wish to view all critical events generated by other applications executing in different execution contexts on a smart card. The interested events in the other applications can be tagged as shareable interface objects and thus exposed to the first application for access. In one embodiment, SIO identifiers for those SIOs can be designated in such a way as containing a string “criticalEvent”. The first application can thus send a request for all those SIOs with a SIO pattern containing “criticalEvent”. Depending on a parameter settable in the request by the first application, all matched SIOs can be returned by the registration mechanism 104 to the first application or a subset of the matched SIOs can be returned by the registration mechanism 104. In the case of returning the subset, the registration mechanism may make selection based on a set of criteria given in the parameters in the request. Additionally or alternatively, the registration mechanism may make selection of the subset based on some user configurable policies. All variations of returning all or a subset of matched SIOs are within the scope of the present invention.
The term “machine-readable medium” as used herein refers to any medium that participates in providing data that causes a machine to operation in a specific fashion. In an embodiment implemented using computer system 500, various machine-readable media are involved, for example, in providing instructions to processor 504 for execution. Such a medium may take many forms, including but not limited to, non-volatile media, and volatile media. Non-volatile media includes, for example, optical or magnetic disks, such as storage device 510. Volatile media includes dynamic memory, such as main memory 506.
Patent CitationsCited PatentFiling datePublication dateApplicantTitleUS7127605 *May 10, 2000Oct 24, 2006Axalto, Inc.Secure sharing of application methods on a microcontrollerUS20020174224May 13, 2002Nov 21, 2002Scheifler Robert W.Stack-based access controlUS20040019893 *Jul 21, 2003Jan 29, 2004Hepworth Paul J.Systems and methods for interfacing multiple types of object identifiers and object identifier readers to multiple types of applicationsUS20040088562Oct 31, 2002May 6, 2004Schlumberger Malco, Inc.Authentication framework for smart cardsUS20040216150Nov 5, 2002Oct 28, 2004Sun Microsystems, Inc.Systems and methods for providing object integrity and dynamic permission grantsUS20060085421 *Sep 28, 2004Apr 20, 2006International Business Machines CorporationExtensible URI-pattern-based servlet request processing frameworkEP1431862A2Dec 16, 2003Jun 23, 2004Activcard Ireland LimitedUniform framework for security tokensWO2005045735A1Nov 7, 2003May 19, 2005Nokia CorporationMethod and device for controlling installation of applications using operator root certificates* Cited by examinerNon-Patent CitationsReference1Claims, Application No. 06256576.7-2212, 3 pages.2Claims, Application No. 07250044-2212, 3 pages.3Claims, European application No. 06256576.7-2212, 5 pages.4Claims, European application No. 07250044.0-2212, 5 pages.5European Patent Office, "Communication pursuant to Article 94(3) EPC", Application No. 06256576.7-2212, dated Jul. 17, 2008, 4 pages.6European Patent Office, "Communication pursuant to Article 94(3) EPC", Application No. 07250044-2212, dated Jul. 3, 2008, 1 page.7European Patent Office, "European Search Report", European application No. 06256576.7-221, 11 pages.8European Patent Office, "European Search Report", European application No. 07250044.0-2212, 10 pages.9Gong, L. et al., "Going Beyond the Sandbox: An Overview of the New Security Architecture in the Java(TM) Development Kit 1.2", Proceedings of the Usenix Symposium on Internet Technologies and Systems, XP-002250254, Dec. 1997, 10 pages.10Gong, L. et al., "Implementing Protection Domains in the Java(TM) Development Kit 1.2", Proceedings of the Internet Society Symposium on Network and Distributed System Security, XP-002304112, Mar. 1988, 10 pages.11Gong, L. et al., "Java Security Architecture (JDK 1.2)", Internet Citation, XP-002171445, dated Dec. 6, 1998, 62 pages.12Gong, L. et al., "Going Beyond the Sandbox: An Overview of the New Security Architecture in the Java™ Development Kit 1.2", Proceedings of the Usenix Symposium on Internet Technologies and Systems, XP-002250254, Dec. 1997, 10 pages.13Gong, L. et al., "Implementing Protection Domains in the Java™ Development Kit 1.2", Proceedings of the Internet Society Symposium on Network and Distributed System Security, XP-002304112, Mar. 1988, 10 pages.14Molva, Refik et al., "A Distributed Access Control Model for Java", Computer Security, Esorics 2000 Lecture, Notes in Computer Science, Springer-Verlag, 2000, Heidelberg, Berlin, XP-019049349, vol. 1895, 18 pages.15Nagaratnam, Nataraj et al., "Practical delegation for secure distributed object environments", Distributed Systems Engineering, Institute of Physics Publishing, Bristol, Great Britain, vol. 5, No. 4, XP-020073372, Dec. 1, 1998, 12 pages.16Wangham, Michelles et al., "Security Mechanisms for Mobile Agent Platforms Based on SPKI/SDSI Chains of Trust", Software Engineering for Multi-Agent Systems II Lecture Notes in Computer Science, Springer-Verlag, Berlin, vol. 2940, XP-019003515, 2004, 18 pages.Referenced byCiting PatentFiling datePublication dateApplicantTitleUS8196097 *Mar 2, 2007Jun 5, 2012Google Inc.Method and apparatus for extending a software gadgetUS8938684Mar 5, 2010Jan 20, 2015Sap SeModification free cutting of business application user interfacesUS20110078594 *Mar 5, 2010Mar 31, 2011Sap AgModification free cutting of business application user interfacesUS20110078599 *Sep 30, 2009Mar 31, 2011Sap AgModification Free UI Injection into Business ApplicationUS20110078600 *Sep 30, 2009Mar 31, 2011Sap AgModification Free Tagging of Business Application User InterfacesCN103514050A *Jun 19, 2012Jan 15, 2014蔡毓芬Program calling method and mobile deviceEP3041187A1 *Dec 30, 2014Jul 6, 2016Accenture Global Services LimitedMethod and system for communicating information between a mobile device and an enterprise system* Cited by examinerClassifications U.S. Classification719/315, 713/150, 717/150, 719/313International ClassificationG06F9/54Cooperative ClassificationG06F2209/541, G06F9/54European ClassificationG06F9/54Legal EventsDateCodeEventDescriptionOct 31, 2006ASAssignmentOwner name: SUN MICROSYSTEMS, INC., CALIFORNIAFree format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:VIOLLEAU, THIERRY P.;RAVISHANKAR, TANJORE;HILL, MATTHEW R.;REEL/FRAME:018493/0103Effective date: 20061027Jan 18, 2011CCCertificate of correctionApr 16, 2014FPAYFee paymentYear of fee payment: 4Dec 16, 2015ASAssignmentOwner name: ORACLE AMERICA, INC., CALIFORNIAFree format text: MERGER AND CHANGE OF NAME;ASSIGNORS:ORACLE USA, INC.;SUN MICROSYSTEMS, INC.;ORACLE AMERICA, INC.;REEL/FRAME:037306/0556Effective date: 20100212RotateOriginal ImageGoogle Home - Sitemap - USPTO Bulk Downloads - Privacy Policy - Terms of Service - About Google Patents - Send FeedbackData provided by IFI CLAIMS Patent Services