i'd like to focus on what i think is the most straightforward and simplest basis for reversing the board's decision and remanding for further analysis and that's the relationship between the usui piece of prior art the mobile execution environment standard execution environment as ericsson and as that were noted has the concept of a sandbox for untrusted code but it doesn't stop there and it also includes three different security domains for trusted code each with varying levels of access control and you see we teach is that a security manager is necessary to implement three trusted domains but you simply itself doesn't teach how to implement the security manager and there's no evidence in this by the sandbox security model their expert says the same thing on appendix page thirty nine eighty three thirty nine eighty four as for the immediate see untrusted area usui is using the sandbox model that was specifically designed for the you need to have a security manager to combine to comply with these three trusted domains requirement and gong and ochs both provide general architectural guidance on how to implement such a security manager and in fact this is an references to provide a security capability in a mobile like usui well as it was recognized the time sun microsystems in the computer environment had provided in work complex more gran system for access control in the computer virus and in designing g to me which was intended for the micro for the mobile environment sun included a much more basic much more limited security model so when you see he says implemented in the  which is more granular which provides more control and more complexity than sun chose to include in the mobile environment you would necessarily look to the desktop environment which is where this more complex more granular access  judgment there's evidence on both sides of the fence and when it comes to deciding or substantial evidence to see if there is evidence on the other side of the issue you lose if you were here arguing the other side of the case you would doing there is identifying the very high level architectural pieces of how security reference correspond to the general high level structural security manager disclosures a certain claim one of the five ten patent here and recall this claim is really quite basic the key portions  relying on for gong are simply when you implement a security manager you need to have an interception module that receives a request to access the protected resources going calls that a resource manager and then you need to have a decision wisdom chose not to include anything beyond basic j two in the security when it implemented j two me for mobile environment therefore want to stay on the i wouldn't it wouldn't go beyond that and if you accept the premise it's really fair fairly compelling argument and one  references might apply in the in the resource restricted environment of a mobile system and certainly what our expert testifies is these are known methods of providing more  in terms of various arguments that they are arguing now they didn't make for them or i think the more important question is what did the board actually have in front of it in making its decision they had to if we turn to the board's decision on  problem developing software user interface for a very resource limited device a mobile phone which they call s c l d c connection limited device configuration and that had known parameters  desktop type system interconnected with the internet that had complex security parameters and that it was basically directed to a different environment and that was supported by substantial evidence submitted by ericsson showing that sun microsystems the developer of the java system actually consider those two environments very different had different software of different applications each of which required different system requirements in terms of processing power and memory ultimately concluding that it would have been obvious to make that combination i want to dress another point that's been raised is that the concept of the in the x c standard i use to eat references that in the in the actual of the article and contrary to what counsel said erickson did submit testimony and evidence directed to that aspect that usui would use it three domains for the trusted software in the sandbox model the untrusted that those are compliant with the j two with the emmy axes standard so again there is substantial evidence supporting the board's conclusions that there and failed to demonstrate should have construed the claims before addressing the motivation to combine here was clear that was unnecessary to resolve the dispute the elements that were found lacking in usui t c l freely admits that those elements are in use in aspect of the claim and then it be p x ninety four they can see that usui failed to disclose the decision in the model so without the proposed combination there was no need to do a claim construction because petitioner freely one further point they raise a number of new arguments in their briefing that were before the board and one on one thing i would note is they did not raise these requests rehearing before the board so the board never had an opportunity to consider these  is that somehow the m e x e standard itself provide a motivation to make the combination well board address the m e x e standard based on the arguments actually presented during the proceeding and found that there was no motivation based on compliance with the standard as they're arguing now and there is no expert testimony to support their arguments and in fact the expert testimony supports eriksson's position that there are substantial evidence findings if there are no questions from the  penalty when i begin my argument by saying there is no evidence of a particular point in the record i would hope to hear the op only cite the record evidence to support that point and what's critical is that my friend didn't defend the board's mistake on appendix page thirty two and i began my argument but there is no evidence and erickson has never argued that j to me on its own was sufficient to be compliant with any excess that mistake this belief that sun microsystems in j toomey itself had already included a security manager that was compliant with him he actually he did the boards analysis of whether there was a motivation to add a security manager using gong ochs onto the  sent boxing on it's own is not sufficient to comply with any actually standard so when you really have here is frankly just it's a round hole and around peg sui says you need a security manager to provide this book to known methods of providing more granular access control indeed that have been used in the job environment like kong and sunset we're going to do something less complicated on the mobile system  said you need to do something more complicated we're going to still new york look for that one skill in the art would go back and look at the known more complex methods of of security control that had already been used their expert doesn't say where else one would look that's really analysis was based on a false promise the board said hold on some microsystems already has and i mean x e compliant security manager in java to micro dish why would you go out and do more with that why would you add on these more resource heavy  intensive complicated security management systems when you already have a perfectly good security manager in usui that already satisfies him e x e that i think is the essence of the board's understanding why that were project our experts testimony it's simply didn't understand i'm sorry not you need to go beyond i mean you need to go beyond j to any in order to satisfy any x e you need to add a more complicated security manager onto the basic java two mobile edition environment and so the arguments that say you wouldn't do anything more complicated than some has already done simply fall away and we think those were crucial to the board's analysis and we simply asked to return to the board and without mistake correction to after the proceedings